Solución:
Otra opción, una que acabo de aprender, proviene de la sqlcmd documentación. Necesita configurar la página de códigos para sqlcmd para que coincida con el de la codificación del archivo. En el caso de UTF-8, la página de códigos es 65001, por lo que querrá:
SQLCMD -S .MSSQLSERVER08 -V 17 -E -i %~dp0aqualogyDB.sql -o %~dp0databaseCreationLog.log
-f 65001
A partir de los comentarios, el problema no está exactamente en la tabla o en la forma en que SQLCMD importa los caracteres especiales. Por lo general, las importaciones problemáticas están relacionadas con el formato del propio script.
El propio Management Studio ofrece la opción de guardar con una codificación específica, lo que debería solucionar el problema en el futuro. Cuando guarde un archivo por primera vez (o use guardar como), debe hacer clic en la flecha pequeña cerca del Ahorrar botón, para usar la opción Guardar con codificación.
De forma predeterminada, guarda el archivo en De Europa occidental (1252). Siempre que tengo caracteres especiales, uso UTF8 (aunque tal vez encajaría alguna otra codificación restrictiva) porque suele ser la solución más rápida.
No estoy seguro (por la imagen) de que esté usando SSMS, así que asegúrese de que su propio editor tenga la opción de guardar el archivo en una codificación diferente. De lo contrario, la conversión del archivo en un editor inteligente (como ya lo probó en Notepad ++) generalmente funciona. Aunque eso podría no funcionar si está convirtiendo de una codificación amplia a una más estrecha y luego de nuevo a una amplia (por ejemplo: de Unicode a ANSI y de regreso a Unicode).
Este tipo de cosas es muy complicado porque se hacen muchas cosas sin decírselo.
Lo primero que haría es usar sqlcmd para mostrar la cadena. Si se muestra correctamente en la ventana cmd.exe, ese es un hecho útil. A continuación, seleccionaría la fila converting la cadena a varbinary para ver qué bytes están realmente allí. creo cartografía aparecerá como 0x636172746f67726166c3ad61, donde la “i” acentuada está representada por los bytes c3ad, que es la codificación UTF-8 para ese carácter. No es bueno tener UTF-8 en una columna de español moderno (Windows 1252). El valor de byte en Windows 1252 para ese carácter es 237 decimal (ED hexadecimal).
Si la columna contiene datos mal codificados, entonces el error radica en cómo se insertó. Quizás eliminando la N inicial en las constantes de cadena – N'string' le dice a SQL Server que genere una cadena Unicode, pero simple 'string' indica que los caracteres usan la codificación del cliente; insertaría español moderno en lugar de Unicode.
Si la columna contiene datos correctamente codificados, diría que encontró un error en la pantalla de la GUI.
Si no puede hacer que sqlcmd inserte los datos correctamente (a la izquierda o no), entonces quiere quejarse a Microsoft. Cuando lo haga, podrá mostrar los bytes almacenados en la columna, utilizando convert(colname as varbinary) – será fundamental para explicar qué va mal.