Felsök Microsoft OLE DB-drivrutinen för SQL Server

gäller för:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics SQL-databas i Microsoft Fabric

Använd denna artikel för att identifiera felstadiet i en OLE DB-operation, välj nästa kontroll och hitta detaljerade felsökningsinstruktioner. Vägledningen använder den nuvarande leverantören, MSOLEDBSQL19. För versionsspecifika defekter och uppdateringsändringar, se Kända problem och större versionsskillnader.

Identifiera symtomet

Spara den fullständiga felbeskrivningen och alla tillgängliga felposter innan du ändrar inställningarna. En toppnivå HRESULT, såsom DB_E_ERRORSOCCURRED, identifierar inte orsaken på egen hand. Registrera om felet inträffar vid laddning av leverantören, öppnande av en anslutning, utförande av ett kommando, dataupptagning eller genomförande av en transaktion.

Symptom	Börja här
Leverantören kan inte hittas, eller så är klassen inte registrerad.	Leverantörsregistrering och arkitektur
Inloggning misslyckas, åtkomst nekas eller integrerad autentisering misslyckas.	Inloggnings- och autentiseringsfel
Certifikatkedjan är inte betrodd, eller så stämmer inte certifikatets namn.	TLS-certifikatfel
Server eller instans kan inte hittas, eller så nekas anslutningen.	Nätverks- och instansupptäcktsfel
Parametrar misslyckas, värden trunkeras eller data kan inte konverteras.	Misstag i parameter- och datakonvertering
Anslutningen bryts, återställningen misslyckas eller så går en timeout ut.	Anslutningsbortfall och tidsgränser
Felinformation saknas, eller så behöver du en spårningslogg för supporten.	Diagnostik och spårning

För anslutningsfel, jämför applikationen med ett Universal Data Link (UDL)-anslutningstest. Använd samma dator, leverantör, processarkitektur, autentiseringsidentitet, server, databas och krypteringsinställningar. Ett lyckat test med en annan leverantör eller identitet fastställer inte att applikationens konfiguration fungerar.

Leverantörsregistrering och arkitektur

Fel som Provider kan inte hittas eller REGDB_E_CLASSNOTREG (0x80040154, Klass ej registrerad) indikerar att leverantören laddas före SQL Server-autentificering.

Kontrollera vilken leverantör som ansökan efterfrågar. MSOLEDBSQL19 och MSOLEDBSQL identifiera olika huvudversioner. Att installera den aktuella drivrutinen ändrar inte applikationens leverantörsval. Följ migreringsstegen om applikationen fortfarande begär en annan leverantör.
Kontrollera arkitekturen för processen som är värd för applikationen. En 32-bitars applikation behöver 32-bitars leverantören, även på 64-bitars Windows. För en tjänst eller ett schemalagt jobb, kontrollera den körbara filen och kontot som används på den värden, inte bara din utvecklingsmiljö.
Installera eller reparera drivrutinen med den stödda installationsfilen på datorn som kör applikationen. x64-installationsprogrammet inkluderar både 64-bitars och 32-bitars drivrutinsbinärer. Kontrollera de nödvändiga beroendena i Install the OLE DB Driver och Systemkrav. Kopiera inte drivrutinsbibliotek från en annan dator som ersättning för installation.
Upprepa UDL-testet med matchningsarkitektur och leverantör. Om det fungerar men applikationen ändå inte kan ladda leverantören, jämför applikationens effektiva leverantörsval och värdarkitektur med testet.

Om felet specifikt nämner adal.dll, se det kända problemet med autentiseringsbiblioteket i stället för att behandla det som en saknad provider för SQL Server.

Skilj på avslag på serverinloggning och misslyckande med att erhålla inloggningsuppgifter eller upprätta en krypterad anslutning. Läs hela felmeddelandet, inklusive eventuella inbäddade leverantörsfel.

För SQL Server-fel 18456, be databasadministratören att inspektera motsvarande serverfelloggpost och status. Kontrollera autentiseringsläget, inloggningsstatus, begärd databas och databasåtkomst med MSSQLSERVER_18456. Anta inte att varje avslag på inloggning betyder ett felaktigt lösenord.
För integrerad autentisering, bekräfta identiteten som applikationen körs under. Ett tjänstekonto eller ett konto för schemalagd aktivitet kan skilja sig från den användare som har testat anslutningen. Om meddelandet innehåller Kan inte generera SSPI-kontext, följ Security Support Provider Interface (SSPI) felsökning och Support för Service Principal Name (SPN).
För Microsoft Entra ID, kontrollera att den valda autentiseringsmetoden passar applikationens exekveringsmiljö och att dess identitet har tillgång till måldatabasen. Gå igenom metodspecifika inställningar och åtkomsttokenbegränsningar i Use Microsoft Entra ID. Kombinera inte en åtkomsttoken med motstridiga autentiserings- eller inloggningsegenskaper.
Jämför de effektiva inställningarna med rätt reťazec pripojenia-nyckelordstabell. IDBInitialize::Initialize, IDataInitialize::GetDataSource, och ActiveX Data Objects (ADO) använder olika nyckelordstabeller. Kolla tabellen för gränssnittet som din applikation använder.

Texten Det målinriktade huvudnamnet är felaktigt kan förekomma i olika sammanhang. Om det åtföljs av Kan inte generera SSPI-kontext undersöker du Windows-autentisering och SPN:er. Om felet identifierar certifikatet eller krypteringshandshake, använd nästa avsnitt.

TLS-certifikatfel

Transport Layer Security (TLS)-fel kan uppstå innan en inloggning når SQL Server. Den nuvarande drivrutinen möjliggör obligatorisk kryptering som standard, så en uppgradering kan avslöja ett certifikatförtroende- eller namnproblem som en äldre anslutningskonfiguration inte upptäckte.

För Certifikatkedjan utfärdades av en auktoritet som inte är betrodd, kontrollera certifikatet som SQL Server presenterar och den utfärdande certifikatkedjan som klientdatorn litar på. Konfigurera ett giltigt servercertifikat och installera de nödvändiga betrodda root- och mellancertifikaten via organisationens certifikathanteringsprocess.
Vid en missanpassning av certifikatnamn, jämför server- eller lyssnarnamnet som applikationen använder med namnen i certifikatet. Använd ett certifikat som täcker det avsedda anslutningsnamnet. Om applikationen medvetet använder ett annat anslutningsnamn, granska den dokumenterade egenskapen HostNameInCertificate innan du konfigurerar det förväntade certifikatnamnet.
Kontrollera de effektiva krypterings- och valideringsinställningarna, inklusive registerinställningar. Gå igenom tabellerna för kryptering och certifikatvalidering för prioritet och Strict beteende. I Strict läge validerar drivrutinen certifikatet oavsett inställningen för trust-server-certifikat.
Om felet började under migreringen, se felsökning för huvudversioner, inklusive värdetypen för krypteringsegenskapen och begränsningen för att använda ServerCertificate utanför Strict-läge.

Använd certifikatkraven för SQL Server och felsökning av ej betrodd certifikatkedja för detaljerade kontroller. Ha kryptering och certifikatvalidering aktiverad i produktion. Att inaktivera någon av dem löser inte problemet med certifikatutplacering.

Nätverks- och instansupptäcktsfel

För servern hittades inte, fel vid lokalisering av angiven server/instans eller fel om nekad anslutning, identifiera den ändpunkt som applikationen försöker nå.

Verifiera servernamn, instansnamn och konfigurerad lyssningsport med databasadministratören. Bekräfta att databastjänsten körs och att det avsedda protokollet och lyssnaren är aktiverade. Anta inte att varje instans lyssnar på port 1433.
För en fjärranslutning med Transmission Control Protocol (TCP), testa den kända ändpunkten genom att använda drivrutinens tcp:<server>,<port> servernamnsformat. Behåll samma autentiserings-, databas- och krypteringsinställningar. Se Connection string-nyckelord för servernyckelordet som gäller för ditt gränssnitt.
Om det fungerar med ett explicit angivet värdnamn och en port, men inte med den namngivna instansen, undersök SQL Server Browser och instansidentifiering. Kontrollera webbläsartjänsten och User Datagram Protocol (UDP)-porten 1434-sökvägen där webbläsarupptäckt används.
Om den explicita ändpunkten också misslyckas, kontrollera Domain Name System (DNS)-upplösning, routing och brandväggsåtkomst till den faktiska lyssningsporten från applikationsvärden. Följ nätverksrelaterade eller instansspecifika anslutningsfel istället för att ändra flera anslutningsinställningar samtidigt.

För en tillgänglighetsgruppslyssnare, granska även stöd för hög tillgänglighet och katastrofåterställning. För LocalDB, använd LocalDB-stöd för att kontrollera den lokala instansen och användarkontexten istället för att tillämpa fjärrupptäcktssteg för TCP.

Misstag i parameter- och datakonvertering

Om anslutningen öppnas men kommandoexekvering eller datahämtning misslyckas, minska reproduktionen till det felande kommandot och värdet. Bevara den ursprungliga datatypen, längden, nollstatusen och teckenkodningen när du byter ut känslig data.

Jämför varje ? parametermarkör med dess bindningsordning, riktning och metadata. När du använder ICommandWithParameters::SetParameterInfo, matchar SQL-källkoden med kommandot eller den lagrade proceduren. Anta inte att parametermetadata alltid härleds automatiskt. Gå igenom kommandoparametrar för härledningsbegränsningar och utdataparameterbeteende.
Inspektera status för accessorbindningar samt status och längd för varje returnerat värde, inte bara den övergripande HRESULT. Vid fel när egenskaper anges, kontrollera varje egenskaps dwStatus. En partiell framgångsretur, såsom DB_S_ERRORSOCCURRED , kan kräva statusarrayinspektion även när inget felobjekt är tillgängligt. Se returkoder.
Vid konvertering eller avkortning ska du jämföra konsumentbuffertens typ och storlek med de faktiska metadata för kolumnen eller parametern. Kontrollera precision och skala för numeriska värden, giltiga intervall och bråkdelar av sekunder för datum/tid, samt bytelängder för teckenbuffertar. Undersök DBSTATUS_E_CANTCONVERTVALUE, och behandla DBSTATUS_S_TRUNCATED inte som ett komplett värde. Använd datatypmappning, hämtande rader samt datum- och tidskonverteringar för tillämpliga regler.
Om begränsade utgångsparametrar verkar saknas, töm de returnerade radmängderna innan du läser dem. Följ Use IMultipleResults för att bearbeta flera resultatuppsättningar. För strömmade utdataparameter, konsumera eller släpp väntande strömmar innan du begär nästa resultat, enligt Streaming-stöd för utdataparametrar.

För ADO-specifika mappningar, se Använd ADO med OLE DB-drivrutinen och autentiseringsbegränsningarna på DataTypeCompatibility i Använd Microsoft Entra ID. Lägg inte till en kompatibilitetsinställning utan att ha kontrollerat båda.

För korrupta smala strängar i en sql_variant kolumn efter en drivrutinsuppgradering, granska det befintliga SSVARIANT-problemet och återställningsproceduren innan du ändrar lagrad data.

Förlorad anslutning och tidsgränsöverskridanden

Registrera när anslutningen senast fungerade, vilken operation som misslyckades och hur länge den pågick. Särskilja dessa fall innan du ändrar inställningar för omprövning eller timeout.

Misslyckat steg	Kontroller och detaljerad vägledning
Öppnar en anslutning.	Inspektera leverantörs-, nätverks-, autentiserings- och TLS-fel först. Kontrollera det effektiva `DBPROP_INIT_TIMEOUT` eller motsvarande länknyckelordet. Se felsökning av tidsgräns för anslutning.
Kör ett kommando.	Kontrollera `DBPROP_COMMANDTIMEOUT` eller inställningen för programmets kommandotidsgräns. Undersök blockering och frågeprestanda med Felsökning av tidsgräns för frågor. Att öka anslutningstimeouten ändrar inte kommandotimeouten.
Återanvänder en ledig anslutning.	Kontrollera återställningsvillkor, inställningar för återförsök och förväntade fel i vilolägesanslutningens resiliens. Återställning kan misslyckas när kommandots tidsavbrott går ut innan återanslutningen är klar.
Anslutningen bryts under körning eller incheckning.	Korrelera klient- och serverhändelser för att kontrollera nätverksavbrott, serveromstart eller failover. Fastställ resultatet av operationen innan du bestämmer om det är säkert att försöka igen.

Motståndskraft för inaktiva anslutningar ger inte återförsök vid den inledande anslutningen eller automatisk upprepning av godtyckliga kommandon och transaktioner. Vid ett bekräftat övergående fel, använd begränsade applikationsförsök med fördröjning och logga varje försök. Försök inte upprepade gånger med fel vid leverantörsinlämning, avvisade inloggningsuppgifter eller certifikatvalideringsfel utan att åtgärda orsaken.

Caution

Om en anslutning avbryts under en skrivning eller en bekräftelse kanske klienten inte vet om SQL Server har bekräftat transaktionen. Spela inte upp operationen i blindo. Kontrollera dess resultat eller använd en applikationsdesign som förhindrar dubbletter innan du försöker igen.

Diagnostik och spårning

Samla diagnostik vid felpunkten innan orelaterade leverantörssamtal ersätter felinformationen.

Fånga den operation som misslyckades, tidsstämpeln och tidszonen, förfluten tid och HRESULT. För native OLE DB-konsumenter, hämta alla tillgängliga poster genom IErrorInfo och IErrorRecords, inte bara den första beskrivningen. Inkludera SQLSTATE och det inbyggda SQL Server-felnumret när det finns tillgängligt via ISQLErrorInfo. Se Hämta felinformation och SQL Server-feldetaljer. För ADO, hämta anslutningens Errors-samling.
Samla in statusar per egenskap, per bindning och per värde för metoder som rapporterar fel på det sättet. Ett frånvarande felobjekt gör inte ett partiellt framgångsresultat säkert att ignorera.
Koppla klientfelet till serverns fellogg eller utökade händelser. När det är möjligt, spela in ClientConnectionID och ActivityID. Ett fel före förinloggning kan inträffa utan en klientanslutningsidentifierare.
Om felposter inte räcker använder du Få åtkomst till diagnostikinformation i loggen för utökade händelser för drivrutinsspårning och korrelationskonfiguration. Samla in ett begränsat spår runt reproduktionen och sluta spåra efteråt.

När du eskalerar, inkludera drivrutinsversion, begärd leverantör, applikations- och processarkitektur, serverversion, autentiseringsmetod, effektiva anslutningsinställningar, felsteg, felposter och minimal reproduktion. Ange om det matchande UDL-testet lyckas och om problemet påverkar en värd eller flera värdar.

Ta bort lösenord, åtkomsttoken och andra hemligheter från anslutningsinställningar och loggar. Granska spår för frågetext och känslig data, lagra dem med begränsad åtkomst och dela dem endast via en godkänd supportkanal.

Feedback

Var den här sidan till hjälp?

Last updated on 2026-09-23