Aggiornamento di un'applicazione da SQL Server 2005 Native Client
Si applica a:
SQL ServerDatabase SQL di AzureIstanza gestita di SQL di AzureAzure Synapse AnalyticsPiattaforma di strumenti analitici (PDW)
Importante
SQL Server Native Client (SNAC) non viene fornito con:
- SQL Server 2022 (16.x) e versioni successive
- SQL Server Management Studio 19 e versioni successive
SQL Server Native Client (SQLNCLI o SQLNCLI11) e il provider OLE DB Microsoft legacy per SQL Server (SQLOLEDB) non sono consigliati per lo sviluppo di nuove applicazioni.
Per i nuovi progetti, usare uno dei driver seguenti:
Per SQLNCLI fornito come componente del motore di database di SQL Server (versioni dal 2012 al 2019), vedere questa Eccezione relativa al ciclo di vita del supporto.
Questo argomento illustra le modifiche di rilievo in SQL Server Native Client perché SQL Server Native Client in SQL Server 2005 (9.x).
Quando si esegue l'aggiornamento da Microsoft Data Access Components (MDAC) a SQL Server Native Client, potrebbero verificarsi anche alcune differenze di comportamento. Per altre informazioni, vedere Aggiornamento di un'applicazione a SQL Server Native Client da MDAC.
SQL Server Native Client 9.0 fornito con SQL Server 2005 (9.x). SQL Server Native Client 10.0 fornito con SQL Server 2008 (10.0.x). SQL Server Native Client 10.5 fornito con SQL Server 2008 R2 (10.50.x). SQL Server Native Client 11.0 fornito con SQL Server 2012 (11.x) e SQL Server 2014 (12.x).
| Modifica del comportamento in SQL Server Native Client a partire da SQL Server 2005 (9.x) | Descrizione |
|---|---|
| In OLE DB viene applicato il riempimento solo in base alla scala definita. | Per le conversioni in cui i dati convertiti vengono inviati al server, SQL Server Native Client (a partire da SQL Server 2008 (10.0.x)) esegue il pad degli zeri finali nei dati solo fino alla lunghezza massima dei valori datetime . In SQL Server Native Client 9.0 viene applicato un riempimento fino a un massimo di 9 cifre. |
| Convalida di DBTYPE_DBTIMESTAMP per ICommandWithParameter::SetParameterInfo. | SQL Server Native Client (a partire da SQL Server 2008 (10.0.x)) implementa il requisito OLE DB per bScale in ICommandWithParameter::SetParameterInfo da impostare sulla precisione dei secondi frazionari per DBTYPE_DBTIMESTAMP. |
| La stored procedure sp_columns restituisce ora "NO" anziché "NO " per la colonna IS_NULLABLE. | A partire da SQL Server Native Client 10.0 (SQL Server 2008 (10.0.x)), sp_columns stored procedure restituisce ora "NO" anziché "NO" per una colonna IS_NULLABLE. |
| SQLSetDescRec, SQLBindParameter e SQLBindCol ora eseguono il controllo coerenza. | Prima di SQL Server Native Client 10.0, l'impostazione SQL_DESC_DATA_PTR non ha causato una verifica coerenza per qualsiasi tipo di descrittore in SQLSetDescRec, SQLBindParameter o SQLBindCol. |
| SQLCopyDesc esegue ora il controllo della coerenza del descrittore. | Prima di SQL Server Native Client 10.0, SQLCopyDesc non esegue una verifica coerenza quando il campo SQL_DESC_DATA_PTR è stato impostato su un record specifico. |
| SQLGetDescRec non esegue più una verifica di coerenza del descrittore. | Prima di SQL Server Native Client 10.0, SQLGetDescRec ha eseguito una verifica di coerenza del descrittore quando è stato impostato il campo SQL_DESC_DATA_PTR. Non è stato richiesto dalla specifica ODBC e in SQL Server Native Client 10.0 (SQL Server 2008 (10.0.x)) e versioni successive, questa verifica coerenza non viene più eseguita. |
| Quando la data non è inclusa nell'intervallo consentito viene restituito un errore differente. | Per il tipo datetime , verrà restituito un numero di errore diverso da SQL Server Native Client (a partire da SQL Server 2008 (10.0.x)) per una data non compreso nell'intervallo restituito nelle versioni precedenti. In particolare, SQL Server Native Client 9.0 ha restituito 22007 per tutti i valori di anno non compresi nell'intervallo nelle conversioni di stringhe in datetime e SQL Server Native Client a partire dalla versione 10.0 (SQL Server 2008 (10.0.x)) restituisce 22008 quando la data è compresa nell'intervallo supportato da datetime2 ma non compreso nell'intervallo supportato da datetime o smalldatetime. |
| Il valore datetime tronca i secondi frazionari e non viene arrotondato se tale arrotondamento comporta la modifica del giorno. | Nelle versioni precedenti a SQL Server Native Client 10.0, il client arrotonda i valori datetime inviati al server al valore più vicino corrispondente a 1/300 di secondo. A partire da SQL Server Native Client 10.0, questo scenario causa un troncamento di secondi frazionari se l'arrotondamento cambia il giorno. |
| Possibile troncamento di secondi per valore datetime. | Un'applicazione compilata con SQL Server 2008 (10.0.x) Native Client (o versione successiva) che si connette a un server SQL Server 2005 tronca i secondi e i secondi frazionari per la parte temporale dei dati inviati al server se si esegue l'associazione a una colonna datetime con un identificatore di tipo di DBTYPE_DBTIMESTAMP (OLE DB) o SQL_TIMESTAMP (ODBC) e una scala pari a 0. Ad esempio: Dati di input: 1994-08-21 21:21:36.000 Dati inseriti: 1994-08-21 21:21:00.000 |
| La conversione dei dati OLE DB da DBTYPE_DBTIME a DBTYPE_DATE non può più causare la modifica del giorno. | Nelle versioni precedenti a SQL Server Native Client 10.0 se la parte relativa all'ora di un tipo DBTYPE_DATE è entro mezzo secondo dalla mezzanotte, il codice di conversione OLE DB causa la modifica del giorno. A partire da SQL Server Native Client 10.0, il giorno non cambierà (i secondi frazionari vengono troncati e non arrotondati). |
| Modifiche della conversione IBCPSession::BCColFmt. | A partire da SQL Server Native Client 10.0, quando si usa IBCPSession::BCOColFmt per convertire SQLDATETIME o SQLDATETIME in un tipo stringa, viene esportato un valore frazionario. Ad esempio, quando si converte il tipo SQLDATETIME in tipo SQLNVARCHARMAX, vengono restituite versioni precedenti di SQL Server Native Client 1989-02-01 00:00:00. SQL Server Native Client 10.0 e versioni successive restituiscono 1989-02-01 00:00:00.00000000. |
| Le dimensioni dei dati inviati devono corrispondere alla lunghezza specificata in SQL_LEN_DATA_AT_EXEC. | Quando si utilizza SQL_LEN_DATA_AT_EXEC, le dimensioni dei dati devono corrispondere alla lunghezza specificata con SQL_LEN_DATA_AT_EXEC. È possibile utilizzare SQL_DATA_AT_EXEC ma l'utilizzo di SQL_LEN_DATA_AT_EXEC comporta vantaggi potenziali in termini di prestazioni. |
| Le applicazioni personalizzate che utilizzano l'API BCP ora possono visualizzare un avviso. | L'API BCP genererà un messaggio di avviso se la lunghezza dei dati di tutti i tipi è superiore a quella specificata per un campo. In precedenza, questo avviso veniva visualizzato solo per i dati di tipo carattere e non per tutti i tipi. |
| Se si inserisce una stringa vuota in una colonna sql_variant associata come tipo data/ora, viene generato un errore. | In SQL Server Native Client 9.0 l'inserimento di una stringa vuota in una colonna sql_variant associata come tipo data/ora non generava alcun errore. SQL Server Native Client 10.0 (e versioni successive) genera correttamente un errore in questa situazione. |
| Convalida dei parametri SQL_C_TYPE _TIMESTAMP e DBTYPE_DBTIMESTAMP più restrittiva. | Prima di SQL Server 2008 (10.0.x) Native Client, i valori datetime sono stati arrotondati per adattarsi alla scala delle colonne datetime e smalldatetime di SQL Server. SQL Server 2008 (10.0.x) Native Client (e versioni successive) applica le regole di convalida più rigorose definite nella specifica di base ODBC per i secondi frazionari. Se non è possibile convertire il valore di un parametro nel tipo SQL utilizzando la scala specificata o implicita dell'associazione client senza causare il troncamento delle cifre finali, viene restituito un errore. |
| Quando è in esecuzione un trigger, SQL Server potrebbe restituire risultati diversi. | Le modifiche introdotte in SQL Server 2008 (10.0.x) potrebbero causare la restituzione di risultati diversi da un'istruzione che ha causato l'esecuzione di un trigger quando NOCOUNT OFF era attivo. In una situazione di questo tipo l'applicazione potrebbe generare un errore. Per risolvere questo errore, impostare NOCOUNT ON nel trigger o chiamare SQLMoreResults per passare al risultato successivo. |