Hacemos una verificación completa cada noticias de nuestro sitio web con el objetivo de enseñarte siempre información con la mayor veracidad y actual.
Solución:
Si necesita conocer la intercalación predeterminada para una base de datos recién creada, utilice:
SELECT SERVERPROPERTY('Collation')
Esta es la intercalación del servidor para la instancia de SQL Server que está ejecutando.
Codificaciones
En la mayoría de los casos, SQL Server almacena datos Unicode (es decir, los que se encuentran en el XML y N-tipos con prefijo) en UCS-2 / UTF-16 (el almacenamiento es el mismo, UTF-16 simplemente maneja los caracteres suplementarios correctamente). Esto no es configurable: no hay opción para usar ya sea UTF-8 o UTF-32 (ver ACTUALIZAR sección en la parte inferior re: UTF-8 a partir de SQL Server 2019). Si las funciones integradas pueden manejar correctamente los caracteres suplementarios, y si se ordenan y comparan correctamente, depende de la intercalación que se utilice. Las colaciones más antiguas: nombres que comienzan con SQL_ (p.ej SQL_Latin1_General_CP1_CI_AS) xor sin número de versión en el nombre (p. ej. Latin1_General_CI_AS) – equiparar todos los caracteres suplementarios entre sí (debido a que no tienen peso de clasificación). A partir de SQL Server 2005, introdujeron el 90 colaciones de series (aquellas con _90_ en el nombre) que al menos podría hacer una comparación binaria en Caracteres Suplementarios para poder diferenciarlos, incluso si no se ordenaron en el orden deseado. Eso también sostiene true Para el 100 intercalaciones de series introducidas en SQL Server 2008. SQL Server 2012 introdujo intercalaciones con nombres que terminan en _SC que no solo clasifica los Caracteres Suplementarios correctamente, sino que también permite que las funciones integradas los interpreten como se espera (es decir, tratando el par sustituto como una sola entidad). A partir de SQL Server 2017, todas las intercalaciones nuevas (el 140 series) admiten implícitamente caracteres suplementarios, por lo que no hay nuevas intercalaciones con nombres que terminen en _SC.
A partir de SQL Server 2019, UTF-8 se convirtió en una codificación compatible para CHAR y VARCHAR datos (columnas, variables y literales), pero no TEXT(ver ACTUALIZAR sección en la parte inferior re: UTF-8 a partir de SQL Server 2019).
Los datos no Unicode (es decir, los que se encuentran en el CHAR, VARCHAR, y TEXT tipos – pero no use TEXT, usar VARCHAR(MAX) en su lugar) utiliza una codificación de 8 bits (ASCII extendido, DBCS o EBCDIC). El conjunto / codificación de caracteres específicos se basa en la página de códigos, que a su vez se basa en la clasificación de una columna, o la clasificación de la base de datos actual para literales y variables, o la clasificación de la instancia para nombres de variables / cursores y GOTO etiquetas, o lo que se especifica en un COLLATE cláusula si se está utilizando una.
Para ver cómo las configuraciones regionales coinciden con las intercalaciones, consulte:
- Nombre de intercalación de Windows
- Nombre de intercalación de SQL Server
Para ver la página de códigos asociada con una colación en particular (este es el conjunto de caracteres y solo afecta CHAR / VARCHAR / TEXT data), ejecute lo siguiente:
SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'CodePage' ) AS [CodePage];
Para ver el LCID (es decir, la configuración regional) asociado con una intercalación en particular (esto afecta las reglas de clasificación y comparación), ejecute lo siguiente:
SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'LCID' ) AS [LCID];
Para ver la lista de intercalaciones disponibles, junto con sus LCID y páginas de códigos asociados, ejecute:
SELECT [name],
COLLATIONPROPERTY( [name], 'LCID' ) AS [LCID],
COLLATIONPROPERTY( [name], 'CodePage' ) AS [CodePage]
FROM sys.fn_helpcollations()
ORDER BY [name];
Defaults
Antes de analizar las intercalaciones predeterminadas del servidor y la base de datos, se debe comprender la importancia relativa de esos valores predeterminados.
La intercalación predeterminada del servidor (instancia, en realidad) se utiliza como predeterminada para las bases de datos recién creadas (incluidas las bases de datos del sistema: master, model, msdb, y tempdb). Pero esto no significa que cualquier base de datos (que no sean las 4 bases de datos del sistema) esté utilizando esa colación. La intercalación predeterminada de la base de datos se puede cambiar en cualquier momento (aunque hay dependencias que pueden evitar que se cambie la intercalación de una base de datos). Sin embargo, la clasificación predeterminada del servidor no es tan fácil de cambiar. Para obtener detalles sobre cómo cambiar todas las intercalaciones, consulte: Cambiar la intercalación de la instancia, las bases de datos y todas las columnas en todas las bases de datos de usuario: ¿Qué podría salir mal?
Los controles de intercalación de instancias / servidores:
- variable local nombres
CURSORnombresGOTOetiquetas- Metadatos a nivel de instancia
La intercalación predeterminada de la base de datos se utiliza de tres formas:
- como predeterminado para los recién creados string columnas. Pero esto no significa que ninguna string columna está usando esa colación. La clasificación de una columna se puede cambiar en cualquier momento. Aquí, conocer el valor predeterminado de la base de datos es importante como una indicación de lo que string Es muy probable que las columnas estén configuradas en.
- como colación para operaciones que involucran string literales, variables y funciones integradas que no toman string entradas pero produce una string salida (es decir
IF (@InputParam = 'something')). Aquí, conocer el valor predeterminado de la base de datos es definitivamente importante, ya que gobierna cómo se comportarán estas operaciones. - Metadatos a nivel de base de datos
La columna Collation se especifica en el COLLATE cláusula en el momento de la CREATE TABLE o un ALTER TABLE table_name ALTER COLUMNo, si no se especifica, tomado de la base de datos predeterminada.
Dado que hay varias capas aquí donde se puede especificar una intercalación (base de datos predeterminada / columnas / literales y variables), la intercalación resultante está determinada por la precedencia de la intercalación.
Dicho todo esto, la siguiente consulta muestra la configuración predeterminada / actual para el sistema operativo, la instancia de SQL Server y la base de datos especificada:
SELECT os_language_version,
---
SERVERPROPERTY('LCID') AS 'Instance-LCID',
SERVERPROPERTY('Collation') AS 'Instance-Collation',
SERVERPROPERTY('ComparisonStyle') AS 'Instance-ComparisonStyle',
SERVERPROPERTY('SqlSortOrder') AS 'Instance-SqlSortOrder',
SERVERPROPERTY('SqlSortOrderName') AS 'Instance-SqlSortOrderName',
SERVERPROPERTY('SqlCharSet') AS 'Instance-SqlCharSet',
SERVERPROPERTY('SqlCharSetName') AS 'Instance-SqlCharSetName',
---
DATABASEPROPERTYEX(N'database_name', 'LCID') AS 'Database-LCID',
DATABASEPROPERTYEX(N'database_name', 'Collation') AS 'Database-Collation',
DATABASEPROPERTYEX(N'database_name', 'ComparisonStyle') AS 'Database-ComparisonStyle',
DATABASEPROPERTYEX(N'database_name', 'SQLSortOrder') AS 'Database-SQLSortOrder'
FROM sys.dm_os_windows_info;
Instalación predeterminada
Otra interpretación de “predeterminado” podría significar qué clasificación predeterminada se selecciona para el Nivel de instancia colación al instalar. Eso varía según el idioma del sistema operativo, pero el valor predeterminado (horrible, horrible) para los sistemas que usan “inglés de EE. UU.” Es SQL_Latin1_General_CP1_CI_AS. En ese caso, la codificación “predeterminada” es la página de códigos de Windows 1252 para VARCHAR datos, y como siempre, UTF-16 para NVARCHAR datos. Puede encontrar la lista del idioma del sistema operativo para la intercalación predeterminada de SQL Server aquí: Compatibilidad con intercalación y Unicode: intercalaciones a nivel de servidor. Tenga en cuenta que estos valores predeterminados pueden anularse; esta lista es simplemente lo que utilizará la instancia si no se anula durante la instalación.
ACTUALIZACIÓN 2018-10-02
SQL Server 2019 presenta soporte nativo para UTF-8 en VARCHAR / CHAR tipos de datos (no TEXT!). Esto se logra mediante un conjunto de nuevas intercalaciones, cuyos nombres terminan con _UTF8. Esta es una capacidad interesante que definitivamente ayudará a algunas personas, pero tiene algunas “peculiaridades”, especialmente cuando UTF-8 no se usa para todas las columnas. y la intercalación predeterminada de la base de datos, así que no la use solo porque haya escuchado que UTF-8 es mágicamente mejor. UTF-8 fue diseñado solamente para compatibilidad con ASCII: para permitir que los sistemas de solo ASCII (es decir, UNIX en el pasado) admitan Unicode sin cambiar ningún código o archivo existente. El hecho de que ahorre espacio para los datos utilizando principalmente (o solo) caracteres del inglés de EE. UU. (Y algo de puntuación) es un efecto secundario. Cuando no se utilizan principalmente (o solo) caracteres del inglés de EE. UU., Los datos pueden tener el mismo tamaño que UTF-16, o incluso más, según los caracteres que se estén utilizando. Y, en los casos en que se ahorra espacio, el rendimiento puede mejorar, pero también puede empeorar.
Para obtener un análisis detallado de esta nueva característica, consulte mi publicación, “Compatibilidad nativa con UTF-8 en SQL Server 2019: ¿Salvador o falso profeta?”.
La codificación de caracteres predeterminada para una base de datos de SQL Server es iso_1, que es ISO 8859-1. Tenga en cuenta que la codificación de caracteres depende del tipo de datos de una columna. Puede tener una idea de qué codificaciones de caracteres se utilizan para las columnas en una base de datos, así como las intercalaciones que utilizan este SQL:
select data_type, character_set_catalog, character_set_schema, character_set_name, collation_catalog, collation_schema, collation_name, count(*) count
from information_schema.columns
group by data_type, character_set_catalog, character_set_schema, character_set_name, collation_catalog, collation_schema, collation_name;
Si usa el valor predeterminado, character_set_name debe ser iso_1 para los tipos de datos char y varchar. Dado que nchar y nvarchar almacenan datos Unicode en formato UCS-2, el character_set_name para esos tipos de datos es UNICODE.
Te invitamos a avalar nuestro trabajo exponiendo un comentario y puntuándolo te damos la bienvenida.