Solución:
Los siguientes artículos tienen buena información sobre la cuestión. La respuesta corta es solo que hay una falta de coincidencia de tipos entre la columna Unicode y el literal de cadena no Unicode que está utilizando. Según el artículo de KB, parece que omitir el prefijo N podría funcionar en algunos casos, pero dependería de la página de códigos y la configuración de clasificación de la base de datos. Eso podría explicar el cambio de comportamiento, si anteriormente estaba teniendo éxito con el método sin prefijo.
https://support.microsoft.com/en-us/kb/239530
Esto denota que la siguiente cadena está en Unicode (la N en realidad significa juego de caracteres de idioma nacional). Lo que significa que está pasando un valor NCHAR, NVARCHAR o NTEXT, en lugar de CHAR, VARCHAR o TEXT. Consulte el artículo 2354 para ver una comparación de estos tipos de datos.
Unicode se utiliza normalmente en aplicaciones de bases de datos que están diseñadas para facilitar las páginas de códigos que se extienden más allá de las páginas de códigos en inglés y Europa Occidental, por ejemplo, en chino. Unicode está diseñado para que los conjuntos de caracteres extendidos aún puedan “caber” en las columnas de la base de datos.
Creo que el prefijo N le dice al servidor SQL que trate la cadena como un valor Unicode. Las columnas nvarchar son Unicode, por lo que debe usar esta sintaxis cuando acceda a estas columnas.