Actualizar una aplicación desde SQL Server 2005 Native Client
Se aplica a: SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)
Importante
SQL Server Native Client (SNAC) no se incluye con:
- SQL Server 2022 (16.x) y versiones posteriores
- SQL Server Management Studio 19 y versiones posteriores
Sql Server Native Client (SQLNCLI o SQLNCLI11) y el proveedor MICROSOFT OLE DB heredado para SQL Server (SQLOLEDB) no se recomiendan para el desarrollo de aplicaciones nuevas.
En el caso de los proyectos nuevos, use uno de los siguientes controladores:
Para SQLNCLI que se incluye como componente de motor de base de datos de SQL Server (versiones 2012 a 2019), consulte esta excepción de ciclo de vida de soporte técnico.
En este tema se describen los cambios importantes en SQL Server Native Client desde SQL Server Native Client en SQL Server 2005 (9.x).
Al actualizar de Microsoft Data Access Components (MDAC) a SQL Server Native Client, es posible que también vea algunas diferencias de comportamiento. Para obtener más información, consulte Actualización de una aplicación a SQL Server Native Client desde MDAC.
SQL Server Native Client 9.0 se incluyó en SQL Server 2005 (9.x). SQL Server Native Client 10.0 se incluye con SQL Server 2008 (10.0.x). SQL Server Native Client 10.5 se incluye con SQL Server 2008 R2 (10.50.x). SQL Server Native Client 11.0 se incluyó en SQL Server 2012 (11.x) y SQL Server 2014 (12.x).
Comportamiento cambiado en SQL Server Native Client desde SQL Server 2005 (9.x) | Descripción |
---|---|
OLE DB solamente rellena los datos hasta la escala definida. | Para las conversiones en las que se envían datos convertidos al servidor, SQL Server Native Client (a partir de SQL Server 2008 (10.0.x)) rellena ceros finales en los datos solo hasta la longitud máxima de los valores datetime . En SQL Server Native Client 9.0 los datos se rellenaban hasta 9 dígitos. |
Valide DBTYPE_DBTIMESTAMP para ICommandWithParameter::SetParameterInfo. | SQL Server Native Client (a partir de SQL Server 2008 (10.0.x)) implementa el requisito OLE DB de bScale en ICommandWithParameter::SetParameterInfo para establecerse en la precisión de fracciones de segundos para DBTYPE_DBTIMESTAMP. |
El procedimiento almacenado sp_columns ahora devuelve "NO" en lugar de "NO " para la columna IS_NULLABLE. | A partir de SQL Server Native Client 10.0 (SQL Server 2008 (10.0.x)), sp_columns procedimiento almacenado ahora devuelve "NO" en lugar de "NO" para una columna de IS_NULLABLE. |
SQLSetDescRec, SQLBindParameter y SQLBindCol ahora realizan comprobaciones de coherencia. | Antes de SQL Server Native Client 10.0, establecer SQL_DESC_DATA_PTR no provocaba una comprobación de coherencia para ningún tipo de descriptor en SQLSetDescRec, SQLBindParameter o SQLBindCol. |
SQLCopyDesc ahora realiza la comprobación de coherencia del descriptor. | Antes de SQL Server Native Client 10.0, SQLCopyDesc no realizó una comprobación de coherencia cuando el campo SQL_DESC_DATA_PTR se estableció en un registro determinado. |
SQLGetDescRec ya no realiza una comprobación de coherencia del descriptor. | Antes de SQL Server Native Client 10.0, SQLGetDescRec realizó una comprobación de coherencia del descriptor cuando se estableció el campo SQL_DESC_DATA_PTR. La especificación ODBC no requería esto y en SQL Server Native Client 10.0 (SQL Server 2008 (10.0.x)) y versiones posteriores, esta comprobación de coherencia ya no se realiza. |
Se devuelve un error distinto cuando la fecha se encuentra fuera del intervalo. | Para el tipo datetime , SQL Server Native Client devolverá un número de error diferente (a partir de SQL Server 2008 (10.0.x)) para una fecha fuera del intervalo que se devolvió en versiones anteriores. En concreto, SQL Server Native Client 9.0 devolvió 22007 para todos los valores de año fuera del intervalo en conversiones de cadena a datetime y SQL Server Native Client a partir de la versión 10.0 (SQL Server 2008 (10.0.x)) devuelve 22008 cuando la fecha está dentro del intervalo admitido por datetime2, pero fuera del intervalo admitido por datetime o smalldatetime. |
El valor datetime trunca las fracciones de segundo y no se redondea si el redondeo cambia el día. | En versiones anteriores a SQL Server Native Client 10.0, el comportamiento del cliente para los valores datetime que se enviaban al servidor era redondearlos a la fracción 1/300 de segundo más próxima. A partir de SQL Server Native Client 10.0, este escenario provoca un truncamiento de fracciones de segundos si el redondeo cambia el día. |
Posible truncamiento de segundos para el valor datetime. | Una aplicación compilada con SQL Server 2008 (10.0.x) Native Client (o posterior) que se conecta a un servidor de SQL Server 2005 truncará segundos y fracciones para la parte de tiempo de los datos enviados al servidor si enlaza a una columna datetime con un identificador de tipo de DBTYPE_DBTIMESTAMP (OLE DB) o SQL_TIMESTAMP (ODBC) y una escala de 0. Por ejemplo: Datos de entrada: 1994-08-21 21:21:36.000 Datos insertados: 1994-08-21 21:21:00.000 |
La conversión de datos OLE DB de DBTYPE_DBTIME a DBTYPE_DATE ya no puede hacer que cambie el día. | En versiones anteriores a SQL Server Native Client 10.0, si la parte correspondiente a la hora de DBTYPE_DATE se encontraba a medio segundo de la medianoche, el código de conversión de OLE DB hacía que el día cambiara. A partir de SQL Server Native Client 10.0, el día no cambiará (las fracciones de segundo se truncan y no se redondean). |
Cambios en la conversión IBCPSession::BCColFmt. | A partir de SQL Server Native Client 10.0, cuando se usa IBCPSession::BCOColFmt para convertir SQLDATETIME o SQLDATETIME en un tipo de cadena, se exporta un valor fraccionario. Por ejemplo, al convertir el tipo SQLDATETIME en el tipo SQLNVARCHARMAX, se devolvieron versiones anteriores de SQL Server Native Client. 1989-02-01 00:00:00. SQL Server Native Client 10.0 y versiones posteriores devuelven 1989-02-01 00:00:00.0000000. |
El tamaño de los datos enviados debe coincidir con la longitud especificada en SQL_LEN_DATA_AT_EXEC. | Cuando se utiliza SQL_LEN_DATA_AT_EXEC, el tamaño de los datos debe coincidir con la longitud especificada en SQL_LEN_DATA_AT_EXEC. Puede usar SQL_DATA_AT_EXEC, pero resulta mucho más ventajoso desde el punto de vista del rendimiento utilizar SQL_LEN_DATA_AT_EXEC. |
Ahora, las aplicaciones personalizadas que utilizan la API de BCP pueden recibir una advertencia. | La API de BCP generará un mensaje de advertencia si la longitud de los datos es mayor que la longitud especificada en un campo para todos los tipos. Anteriormente, esta advertencia solo se recibía para los tipos de caracteres, pero no se emitía para todos los tipos. |
Si se inserta una cadena vacía en un sql_variant enlazado como un tipo de fecha y hora, se genera un error. | En SQL Server Native Client 9.0, al insertar una cadena vacía en un elemento sql_variant enlazado como un tipo de fecha y hora no se generaba ningún error. SQL Server Native Client 10.0 (y versiones posteriores) genera correctamente un error en esta situación. |
Validación de parámetros SQL_C_TYPE_TIMESTAMP y DBTYPE_DBTIMESTAMP más estricta. | Antes de SQL Server 2008 (10.0.x) Native Client, los valores datetime se redondearon para ajustarse a la escala de las columnas datetime y smalldatetime de SQL Server. SQL Server 2008 (10.0.x) Native Client (y versiones posteriores) aplica las reglas de validación más estrictas definidas en la especificación de núcleo ODBC durante fracciones de segundos. Si un valor de parámetro no puede convertirse en el tipo SQL utilizando la escala especificada o no puede implicarse mediante el enlace del cliente sin que se produzca un truncamiento de los dígitos finales, se devuelve un error. |
SQL Server puede devolver resultados diferentes cuando se ejecuta un desencadenador. | Los cambios introducidos en SQL Server 2008 (10.0.x) pueden hacer que una aplicación devuelva otros resultados de una instrucción que ha producido la ejecución de un desencadenador cuando NOCOUNT OFF estaba activo. En esta situación, es posible que la aplicación genere un error. Para resolver este error, establezca NOCOUNT ON en el desencadenador o llame a SQLMoreResults para avanzar al siguiente resultado. |