Risolvere il problema del Microsoft OLE DB Driver per SQL Server

Si applica a:SQL Server Database SQL di Azure Istanza gestita di SQL di Azure Azure Synapse Analytics Database SQL in Microsoft Fabric

Usa questo articolo per identificare la fase di guasto di un'operazione OLE DB, scegliere il controllo successivo e trovare istruzioni dettagliate per la risoluzione dei problemi. La guida utilizza il fornitore attuale, MSOLEDBSQL19. Per difetti specifici della release e modifiche all'aggiornamento, vedi Problemi noti e differenze principali nelle versioni.

Identifica il sintomo

Acquisisci la descrizione completa dell'errore e tutti i record di errore disponibili prima di cambiare impostazioni. Un livello superiore HRESULT, come DB_E_ERRORSOCCURRED, non identifica la causa da solo. Registra se il guasto si verifica durante il caricamento del provider, l'apertura di una connessione, l'esecuzione di un comando, il recupero dei dati o l'effettuazione di una transazione.

Sintomo	Iniziare da qui
Il fornitore non si trova o la classe non è registrata.	Registrazione e architettura dei fornitori
L'accesso fallisce, l'accesso viene negato o l'autenticazione integrata fallisce.	Errori di accesso e autenticazione
La catena di certificati non è affidabile, oppure il nome del certificato non corrisponde.	Errori dei certificati TLS
Server o istanza non possono essere trovati, oppure la connessione viene rifiutata.	Errori di rilevamento di rete e delle istanze
I parametri falliscono, i valori vengono troncati o i dati non possono essere convertiti.	Errori di parametro e conversione dei dati
La connessione cade, il recupero fallisce o scade un timeout.	Perdita di connessione e timeout
Mancano i dettagli dell'errore, oppure occorre una traccia per l'assistenza.	Diagnostica e tracciamento

Per i fallimenti di connessione, confrontare l'applicazione con un test di connessione Universal Data Link (UDL). Usa lo stesso computer, fornitore, architettura di processo, identità di autenticazione, server, database e impostazioni di crittografia. Un test riuscito con un fornitore o un'identità diversa non dimostra che la configurazione dell'applicazione funzioni.

Registrazione e architettura dei fornitori

Errori come Provider non possono essere trovati o REGDB_E_CLASSNOTREG (0x80040154, Classe non registrata) indicano il caricamento del provider prima dell'autenticazione SQL Server.

Controlla il provider richiesto dall'applicazione. MSOLEDBSQL19 e MSOLEDBSQL identificano le diverse versioni principali. L'installazione del driver attuale non cambia la scelta del provider di un'applicazione. Segui i passaggi di migrazione se l'applicazione richiede ancora un altro provider.
Controlla l'architettura del processo che ospita l'applicazione. Un'applicazione a 32 bit necessita del provider a 32 bit, anche su Windows a 64 bit. Per un servizio o un'attività pianificata, controlla l'eseguibile e l'account utilizzati da quell'host, non solo il tuo ambiente di sviluppo.
Installa o ripara il driver con l'installatore supportato sul computer che esegue l'applicazione. L'installatore x64 include sia i binari driver a 64 che a 32 bit. Controlla le dipendenze richieste in Installa il driver OLE DB e i requisiti di sistema. Non copiare librerie di driver da un altro computer come sostituto dell'installazione.
Ripeti il test UDL con l'architettura e il provider di corrispondenza. Se funziona ma l'applicazione non riesce comunque a caricare il provider, confronta la selezione efficace del provider e l'architettura host dell'applicazione con il test.

Se l'errore indica un nome adal.dllspecifico, controlla il problema della libreria di autenticazione conosciuta invece di considerarlo come un provider SQL Server mancante.

Distinguere un rifiuto di login server da un mancato ottenimento di credenziali o di instaurazione di una connessione criptata. Leggi il testo completo dell'errore, incluso qualsiasi errore del provider annidato.

Per l'errore 18456 di SQL Server, chiedi all'amministratore del database di ispezionare la corrispondente voce e lo stato del log di errore del server. Controlla la modalità di autenticazione, lo stato di accesso, il database richiesto e l'accesso al database usando MSSQLSERVER_18456. Non dare per scontato che ogni rifiuto di accesso significhi una password errata.
Per l'autenticazione integrata, confermare l'identità sotto cui l'applicazione funziona. Un account di servizio o un account di attività pianificata può essere diverso dall'utente che ha testato con successo la connessione. Se il messaggio include Impossibile generare il contesto SSPI, segui la procedura di risoluzione dei problemi relativi a Security Support Provider Interface (SSPI) e il supporto per Service Principal Name (SPN).
Per Microsoft Entra ID, verifica che il metodo di autenticazione selezionato si adatti all'ambiente di esecuzione dell'applicazione e che la sua identità abbia accesso al database di destinazione. Esaminare le impostazioni specifiche del metodo e le restrizioni dei token di accesso in Use Microsoft Entra ID. Non combinare un token di accesso con proprietà di autenticazione o credenziali in conflitto.
Confronta le impostazioni effettive con la tabella delle parole chiave stringa di connessione corretta. IDBInitialize::Initialize, IDataInitialize::GetDataSource, e gli ActiveX Data Objects (ADO) utilizzano tabelle di parole chiave diverse. Controlla la tabella per l'interfaccia che utilizza la tua applicazione.

Il testo Il nome principale target è errato può apparire in contesti diversi. Se è accompagnato da Impossibile generare il contesto SSPI, esaminare l'autenticazione di Windows e gli SPN. Se l'errore identifica il certificato o il handshake di crittografia, utilizzare la sezione successiva.

Guasti ai certificati TLS

Gli errori di Transport Layer Security (TLS) possono verificarsi prima che un login raggiunga SQL Server. L'attuale driver abilita la crittografia obbligatoria di default, quindi un aggiornamento può mettere in luce un problema di fiducia o di nome dei certificati che una configurazione di connessione più vecchia non aveva rilevato.

Per la catena di certificati è stata emessa da un'autorità non affidabile, si verifica il certificato presentato da SQL Server e la catena di certificati di emissione di cui il computer client si fida. Configura un certificato server valido e installa i certificati root e intermedi affidabili richiesti tramite il processo di gestione dei certificati della tua organizzazione.
Per una discrepanza di nome di certificato, confronta il nome del server o dell'ascoltatore utilizzato dall'applicazione con i nomi presenti nel certificato. Usa un certificato che copra il nome della connessione previsto. Se l'applicazione utilizza intenzionalmente un nome di connessione diverso, si verifica la proprietà documentata HostNameInCertificate prima di configurare il nome atteso del certificato.
Controlla le impostazioni effettive di crittografia e validazione, comprese quelle del registro. Rivedere le tabelle di crittografia e validazione dei certificati per verificare precedenza e Strict comportamento. In Strict modalità, il driver valida il certificato indipendentemente dall'impostazione trust-server-certificate.
Se il guasto è iniziato durante la migrazione, verifica la risoluzione dei problemi delle versioni principali, inclusi il tipo di valore della proprietà di crittografia e la restrizione sull'uso ServerCertificate della modalità esterna Strict .

Usare Requisiti dei certificati per SQL Server e Risoluzione dei problemi relativi alla catena di certificati non attendibile per verifiche dettagliate. Mantieni attive la crittografia e la validazione dei certificati in produzione. Disabilitare uno dei due non risolve un problema di distribuzione dei certificati.

Errori di rilevamento della rete e delle istanze

In caso di server non trovato, errore durante l'individuazione del server/dell'istanza specificati o errori di connessione rifiutata, identificare l'endpoint che l'applicazione sta tentando di raggiungere.

Verifica il nome del server, il nome dell'istanza e la porta di ascolto configurata con l'amministratore del database. Conferma che il servizio database sia in esecuzione e che il protocollo e l'ascoltatore previsti siano abilitati. Non dare per scontato che ogni istanza ascolti sulla porta 1433.
Per una connessione TCP remota, verifica l'endpoint noto utilizzando il formato del nome server del driver tcp:<server>,<port>. Mantieni le stesse impostazioni di autenticazione, database e crittografia. Vedi Parole chiave della stringa di connessione per la parola chiave del server applicabile all'interfaccia in uso.
Se l'host esplicito e la porta funzionano ma l'istanza denominata non funziona, verifica SQL Server Browser e il rilevamento delle istanze. Controlla il servizio Browser e il percorso della porta 1434 del Protocollo Datagramma Utente (UDP) dove viene utilizzato il Browser Discovery.
Se anche l'endpoint esplicito non funziona, verifica la risoluzione DNS, il routing e l'accesso attraverso il firewall alla porta effettiva di ascolto dall'host applicativo. Segui errori di connessione legati alla rete o specifici per istanza invece di modificare più impostazioni di connessione contemporaneamente.

Per un ascoltatore di gruppi di disponibilità, consulta anche il supporto ad alta disponibilità e disaster recovery. Per LocalDB, usa il supporto LocalDB per controllare l'istanza locale e il contesto utente invece di applicare passaggi di scoperta TCP remoto.

Errori di parametro e conversione dei dati

Se la connessione si apre ma l'esecuzione del comando o il recupero dei dati non riescono, riduci il caso di riproduzione al comando e al valore che causano l'errore. Conservare il tipo di dato originale, la lunghezza, lo stato nullo e la codifica dei caratteri quando si sostituiscono dati sensibili.

Confronta ogni ? segnaposto di parametro con la relativa posizione ordinale di associazione, direzione e metadati. Quando usi ICommandWithParameters::SetParameterInfo, abbina il tipo di sorgente SQL al comando o alla procedura memorizzata. Non dare per scontato che i metadati dei parametri vengano sempre derivati automaticamente. Rivedere i parametri di comando per le restrizioni di derivazione e il comportamento dei parametri di output.
Ispezionare gli stati di binding degli accessori e lo stato e la lunghezza di ogni valore restituito, non solo il valore complessivo HRESULT. In caso di errori nell'impostazione di proprietà, controllare il dwStatus di ogni proprietà. Un ritorno con successo parziale come DB_S_ERRORSOCCURRED può richiedere l'ispezione dell'array di stato anche quando non è disponibile alcun oggetto di errore. Vedi codici di ritorno.
Per la conversione o il troncamento, confrontare il tipo e la dimensione del buffer del consumer con i metadati effettivi della colonna o del parametro. Controlla precisione e scala per valori numerici, intervalli validi e frazioni di secondo per valori data/ora, e lunghezze di byte per i buffer di caratteri. Esaminare DBSTATUS_E_CANTCONVERTVALUE e non considerare DBSTATUS_S_TRUNCATED come un valore completo. Utilizzare la mappatura dei tipi di dati, il recupero delle righe e le conversioni di data e ora per le regole applicabili.
Se i parametri di output legati risultano mancanti, esaurire i set di righe restituiti prima di leggerli. Segui Usa IMultipleResults per elaborare più set di risultati. Per i parametri di output streaming, consuma o rilascia flussi in sospeso prima di richiedere il prossimo risultato, come descritto nel supporto dello streaming per i parametri di output.

Per le mappature specifiche per ADO, consulta Use ADO con il driver OLE DB e le restrizioni di autenticazione su DataTypeCompatibilityUse Microsoft Entra ID. Non aggiungere un'impostazione di compatibilità senza aver selezionato entrambe.

Per stringhe strette corrotte in una colonna sql_variant dopo un aggiornamento del driver, si rivedere il problema noto e la procedura di recupero SSVARIANT esistenti prima di modificare i dati memorizzati.

Perdita di connessione e timeout

Annota quando la connessione ha funzionato l'ultima volta, quale operazione è fallita e per quanto tempo è durata quell'operazione. Distingui questi casi prima di cambiare le impostazioni di ritentativi o timeout.

Fase non riuscita	Controlli e indicazioni dettagliate
Apertura di una connessione.	Ispeziona prima gli errori di provider, rete, autenticazione e TLS. Controlla `DBPROP_INIT_TIMEOUT` effettivo o la parola chiave di connessione corrispondente. Vedi Risoluzione dei problemi del timeout della connessione.
Esecuzione di un comando.	Controlla `DBPROP_COMMANDTIMEOUT` o l'impostazione del timeout dei comandi dell'applicazione. Analizza i blocchi e le prestazioni delle query con Risoluzione dei problemi di timeout delle query. Aumentare il timeout della connessione non cambia il timeout dei comandi.
Riutilizzo di una connessione inattiva.	Controlla le condizioni di recupero, le impostazioni dei tentativi di ripetizione e gli errori previsti in Resilienza della connessione inattiva. Il recupero può fallire quando il timeout del comando scade prima che la riconnessione si completi.
Perdita della connessione durante l'esecuzione o il commit.	Correla eventi client e server per verificare un'interruzione di rete, un riavvio del server o un failover. Stabilisci l'esito dell'operazione prima di decidere se sia sicuro riprovare.

La resilienza della connessione inattiva non fornisce nuovi tentativi di connessione iniziale né la riesecuzione automatica di comandi e transazioni arbitrari. In caso di errore transitorio confermato, usa tentativi di ripetizione dell'applicazione in numero limitato con un intervallo di attesa e registra ogni tentativo. Non riprovare ripetutamente errori di caricamento del provider, credenziali rifiutate o fallimenti di validazione dei certificati senza correggere la causa.

Caution

Se una connessione si interrompe durante una scrittura o una commit, il client potrebbe non sapere se SQL Server ha effettuato il commit della transazione. Non ripetere l'operazione alla cieca. Controlla il risultato o usa un design applicativo che prevenga effetti duplicati prima di riprovare.

Diagnostica e tracciamento

Raccogli le diagnostiche nel punto di guasto, prima che chiamate di fornitori non correlate sostituiscano le informazioni di errore.

Registrare l'operazione in fallimento, il timestamp e il fuso orario, il tempo trascorso e HRESULT. Per i consumatori nativi di OLE DB, recuperare tutti i record disponibili tramite IErrorInfo e IErrorRecords, non solo la prima descrizione. Includere SQLSTATE e il numero di errore nativo di SQL Server quando disponibile tramite ISQLErrorInfo. Vedi Recupero informazioni sugli errori e dettagli errori di SQL Server. Per ADO, acquisisci la raccolta Errors della connessione.
Raccogli gli stati per proprietà, associazione e valore relativi ai metodi che segnalano gli errori in questo modo. Un oggetto di errore assente non rende sicuro ignorare un risultato con successo parziale.
Correla il fallimento del client con il log degli errori del server o con gli Eventi Estesi. Quando disponibili, registra ClientConnectionID e ActivityID. Un guasto prima del prelogin può verificarsi senza un identificatore di connessione client.
Se i record di errore non sono sufficienti, usa accedi alle informazioni diagnostiche nel log degli eventi estesi per il tracciamento dei driver e per impostare la correlazione. Raccogli una traccia limitata attorno alla riproduzione e poi smetti di tracciare.

Quando si fa escalation, includere la versione del driver, il provider richiesto, l'architettura dell'applicazione e dei processi, la versione server, il metodo di autenticazione, le impostazioni di connessione effettive, la fase di guasto, i record di errore e una riproduzione minima. Dichiarare se il test UDL corrispondente ha avuto successo e se il problema riguarda un host o più host.

Rimuovi password, token di accesso e altri segreti dalle impostazioni di connessione e dai log. Esamina le tracce per il testo delle query e i dati sensibili, memorizzali con accesso limitato e condividile solo tramite un canale di supporto approvato.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-09-23