Řešení potíží s ovladačem Microsoft OLE DB pro SQL Server

platí pro:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics sql database v Microsoft Fabric

Použijte tento článek k identifikaci selhávající fáze operace OLE DB, výběru další kontroly a nalezení podrobných návodů k řešení problémů. Pokyny používají současného poskytovatele, MSOLEDBSQL19. Pro specifické vady a změny aktualizací viz Známé problémy a hlavní rozdíly verzí.

Identifikujte příznak

Před změnou nastavení zaznamenejte kompletní popis chyby a všechny dostupné chybové záznamy. Položka nejvyšší úrovně HRESULT, například DB_E_ERRORSOCCURRED, sama o sobě neurčuje příčinu. Zaznamenejte, zda k selhání dochází při načítání poskytovatele, navázání spojení, vykonání příkazu, načtení dat nebo potvrzení transakce.

Symptom	Začněte tady
Poskytovatele nelze najít, nebo není zaregistrována třída.	Registrace a architektura poskytovatele
Přihlášení selže, přístup je odepřen nebo integrovaná autentizace selže.	Selhání přihlášení a autentizace
Řetězec certifikátů není důvěryhodný, nebo název certifikátu nesedí.	Selhání TLS certifikátů
Server nebo instance nelze najít, nebo je spojení odmítnuto.	Selhání při objevování sítí a instancí
Parametry selžou, hodnoty se zkracují nebo data nelze převést.	Chyby při převodu parametrů a dat
Připojení se přeruší, obnova selže nebo vyprší časový limit.	Ztráta spojení a časové výpadky
Chybí podrobnosti o chybě nebo potřebujete trasování pro podporu.	Diagnostika a trasování

Při poruchách připojení porovnejte aplikaci s testem připojení Universal Data Link (UDL). Používejte stejný počítač, poskytovatele, architekturu procesů, autentizační identitu, server, databázi a nastavení šifrování. Úspěšný test s jiným poskytovatelem nebo identitou neprokazuje, že konfigurace aplikace funguje.

Registrace a architektura poskytovatele

Chyby jako Provider nelze najít nebo REGDB_E_CLASSNOTREG (0x80040154, Třída není registrována) naznačují, že poskytovatel se načítá před autentizací SQL Server.

Zkontrolujte poskytovatele, kterého žádost požaduje. MSOLEDBSQL19 a MSOLEDBSQL označují různé hlavní verze. Instalace aktuálního ovladače nemění výběr poskytovatele aplikace. Pokud aplikace stále žádá jiného poskytovatele, postupujte podle kroků migrace .
Zkontrolujte architekturu procesu, který aplikaci hostuje. 32bitová aplikace potřebuje 32bitového poskytovatele, i na 64bitových Windows. U služby nebo plánované úlohy zkontrolujte spustitelný soubor a účet používaný daným hostitelem, nejen vývojové prostředí.
Nainstalujte nebo opravte ovladač pomocí podporovaného instalátoru na počítači, který aplikaci spouští. Instalátor x64 obsahuje jak 64bitové, tak 32bitové binární soubory ovladačů. Zkontrolujte požadované závislosti v Install the OLE DB Driver and System requirements. Nekopírujte knihovny ovladačů z jiného počítače jako náhradu za instalaci.
Opakujte UDL test s odpovídající architekturou a poskytovatelem. Pokud to funguje, ale aplikace stále nemůže načíst poskytovatele, porovnejte efektivní výběr poskytovatele a architekturu hostitele aplikace s testem.

Pokud chyba výslovně uvádí adal.dll, podívejte se na známý problém s knihovnou pro ověřování, místo abyste to považovali za chybějícího zprostředkovatele SQL Serveru.

Rozlište odmítnutí přihlášení na server od neúspěchu při získání přihlašovacích údajů nebo navázání šifrovaného spojení. Přečtěte si celý text chyby, včetně případné chyby vnořeného poskytovatele.

Pro chybu SQL Server 18456 požádejte správce databáze, aby zkontroloval příslušný záznam a stav chyby serveru. Zkontrolujte režim autentizace, stav přihlášení, požadovanou databázi a přístup k databázi pomocí MSSQLSERVER_18456. Nepředpokládejte, že každé odmítnutí přihlášení znamená špatné heslo.
Pro integrovanou autentizaci ověřte identitu, pod kterou aplikace běží. Servisní účet nebo účet s plánovanými úkoly se může lišit od uživatele, který úspěšně otestoval připojení. Pokud zpráva obsahuje Nelze generovat SSPI kontext, postupujte podle řešení problémů pomocí Security Support Provider Interface (SSPI) a podpory názvu principu služby (SPN).
Pro Microsoft Entra ID zkontrolujte, zda vybraná autentizační metoda odpovídá prostředí pro spuštění aplikace a zda její identita má přístup k cílové databázi. Prostudujte si specifická nastavení a omezení přístupových tokenů v Use Microsoft Entra ID. Nekombinujte přístupový token s protichůdnými autentizačními nebo přihlašovacími vlastnostmi.
Porovnejte efektivní nastavení se správnou tabulkou klíčových slov připojovací řetězec. IDBInitialize::Initialize, IDataInitialize::GetDataSource, a ActiveX Data Objects (ADO) používají různé tabulky klíčových slov. Zkontrolujte tabulku pro uživatelské rozhraní, které vaše aplikace používá.

Text Cílový hlavní název je nesprávný se může objevit v různých kontextech. Pokud ji doprovází zpráva Nelze generovat SSPI kontext, zkontrolujte ověřování systému Windows a nastavení SPN. Pokud se chybová zpráva týká certifikátu nebo navázání šifrovaného spojení, použijte následující část.

Selhání TLS certifikátů

Chyby Transport Layer Security (TLS) mohou nastat ještě před tím, než se přihlášení dostane na SQL Server. Současný ovladač ve výchozím nastavení umožňuje povinné šifrování, takže upgrade může odhalit problém s důvěrou v certifikát nebo název, který starší konfigurace připojení neodhalila.

Řetězec certifikátů byl vydán autoritou, která není důvěryhodná, zkontrolujte certifikát, který server SQL Server předkládá, a řetězec certifikátů vydavatele, kterému klientský počítač důvěřuje. Nakonfigurujte platný serverový certifikát a nainstalujte požadované důvěryhodné root a mezicertifikáty prostřednictvím procesu správy certifikátů vaší organizace.
Pro nesoulad názvů certifikátu porovnejte název serveru nebo posluchače, který aplikace používá, s názvy v certifikátu. Použijte certifikát, který pokrývá zamýšlené jméno spojení. Pokud aplikace záměrně používá jiné jméno připojení, zkontrolujte zdokumentovanou vlastnost HostNameInCertificate před konfigurací očekávaného názvu certifikátu.
Zkontrolujte efektivní nastavení šifrování a validace, včetně nastavení registru. Prohlédněte si tabulky pro ověření šifrování a ověřování certifikátů pro prioritu a Strict chování. V Strict režimu ovladač ověřuje certifikát bez ohledu na nastavení trust-server-certificate.
Pokud selhání začalo během migrace, zkontrolujte řešení problémů s hlavní verzí, včetně typu hodnoty šifrovací vlastnosti a omezení použití ServerCertificate vnějšího Strict režimu.

Podrobné kontroly najdete v tématech požadavky na certifikáty pro SQL Server a řešení potíží s nedůvěryhodným řetězcem certifikátů. Udržujte šifrování a ověřování certifikátů zapnuté i v produkci. Vypnutí kterékoliv z těchto zařízení problém s nasazením certifikátu nevyřeší.

Selhání při objevování sítí a instancí

U chyb server nebyl nalezen, chyba při vyhledávání zadaného serveru/instance nebo chyb odmítnutého připojení určete koncový bod, ke kterému se aplikace pokouší připojit.

Ověřte název serveru, název instance a nastavený naslouchací port u správce databáze. Potvrďte, že databázová služba běží a že zamýšlený protokol i posluchač jsou povoleny. Nepředpokládejte, že každá instance poslouchá na portu 1433.
Pro vzdálené připojení Transmission Control Protocol (TCP) otestujte známý koncový bod pomocí formátu tcp:<server>,<port> serverového jména ovladače. Ponechejte stejná nastavení autentizace, databáze a šifrování. Viz Klíčová slova připojovacího řetězce pro klíčové slovo server, které se vztahuje k vašemu rozhraní.
Pokud explicitně zadaný hostitel a port fungují, ale pojmenovaná instance ne, prověřte službu SQL Server Browser a zjišťování instance. Zkontrolujte službu Browser a cestu k portu 1434 protokolu UDP tam, kde se používá zjišťování prostřednictvím služby Browser.
Pokud selže i explicitní endpoint, zkontrolujte rozlišení systému doménových jmen (DNS), směrování a přístup firewallu k aktuálnímu naslouchacímu portu z hostitele aplikace. Postupujte podle chyb připojení souvisejících se sítí nebo specifických pro danou instanci namísto toho, abyste najednou měnili několik nastavení připojení.

Pro skupinového posluchače dostupnosti si také prohlédněte podporu vysoké dostupnosti a obnovy po havárii. Pro LocalDB použijte podporu LocalDB ke kontrole lokální instance a uživatelského kontextu místo aplikace vzdálených kroků TCP discover.

Chyby při převodu parametrů a dat

Pokud se spojení otevře, ale vykonání příkazu nebo načtení dat selže, omezte reprodukci na selhávající příkaz a hodnotu. Zachovejte původní typ dat, délku, stav nul a kódování znaků při nahrazování citlivých dat.

Porovnejte každou ? značku parametru s jejím pořadím vazby, směrem toku a metadaty. Když použijete ICommandWithParameters::SetParameterInfo, přiřaďte typ SQL zdroje k příkazu nebo uložené procedurě. Nepředpokládejte, že metadata parametrů jsou vždy odvozována automaticky. Zkontrolujte parametry příkazu pro omezení odvození a chování výstupních parametrů.
Prohlédněte stavy vazeb accessorů a stav a délku každé vrácené hodnoty, nejen celkový HRESULT. V případě selhání při nastavování vlastností zkontrolujte atribut dwStatus každé vlastnosti. Částečně úspěšný návrat, například takového, DB_S_ERRORSOCCURRED může vyžadovat kontrolu stavového pole i v případě, že chybový objekt není k dispozici. Viz Návratové kódy.
Pro převod nebo zkrácení porovnejte typ a velikost spotřebitelského bufferu se skutečnými metadaty sloupců nebo parametrů. Zkontrolujte přesnost a škálu pro číselné hodnoty, platné rozsahy a zlomky sekund pro datové/časové hodnoty a délky bajtů pro znakové buffery. Prověřte DBSTATUS_E_CANTCONVERTVALUE a nepovažujte DBSTATUS_S_TRUNCATED za úplnou hodnotu. Pro příslušná pravidla použijte mapování datových typů, načítání řádků a převody dat a času .
Pokud se zdá, že svázané výstupní parametry chybí, před jejich čtením nejprve zpracujte všechny vrácené výsledkové sady. Postupujte podle článku Použití IMultipleResults ke zpracování více sad výsledků. Pro parametry streamovaného výstupu spotřebujte nebo uvolněte čekající streamy před požadavkem na další výsledek, jak je popsáno v Podpora streamování pro výstupní parametry.

Mapování specifická pro ADO najdete v článku Use ADO with the OLE DB Driver a omezení ověřování pro DataTypeCompatibility v článku Use Microsoft Entra ID. Než přidáte nastavení kompatibility, zkontrolujte obojí.

V případě poškozených úzkých řetězců ve sloupci sql_variant po upgradu ovladače si před úpravou uložených dat projděte stávající známý problém SSVARIANT a postup obnovení dat.

Ztráta spojení a časové výpadky

Zaznamenejte, kdy naposledy spojení fungovalo, která operace selhala a jak dlouho tato operace trvala. Rozlište tyto případy před změnou nastavení opakování nebo časového limitu.

Fáze selhání	Kontroly a podrobné pokyny
Otevření připojení	Nejprve zkontrolujte chyby poskytovatele, sítě, autentizace a TLS. Zkontrolujte platnou hodnotu `DBPROP_INIT_TIMEOUT` nebo odpovídající klíčové slovo připojení. Viz Řešení problémů s časovým limitem připojení.
Spuštění příkazu	Zkontrolujte `DBPROP_COMMANDTIMEOUT` nebo nastavení časového limitu příkazu v aplikaci. Prozkoumejte blokování a výkon dotazů pomocí řešení problémů s časovým limitem dotazu. Zvýšení časového limitu připojení nemění časový limit příkazu.
Opětovné použití nečinného připojení.	Zkontrolujte podmínky obnovy, nastavení opakovaného pokusu a očekávané chyby v odolnosti připojení v klidu. Obnova může selhat, když vyprší časový limit příkazu před dokončením opětovného připojení.
Ztráta spojení během provádění nebo potvrzení transakce.	Porovnejte klientské a serverové události, abyste ověřili, zda nedošlo k výpadku sítě, restartu serveru nebo přepnutí na záložní server. Nejprve stanovte výsledek operace, než rozhodnete, zda je bezpečné to zkusit znovu.

Odolnost nečinnosti spojení neumožňuje opakované pokusy o první spojení ani automatické přehrávání libovolných příkazů a transakcí. Pro potvrzené přechodné selhání použijte omezené opakované pokusy s prodlevou a zaznamenávejte každý pokus. Nezkoušejte opakovaně chyby při načítání poskytovatelů, zamítnuté přihlašovací údaje nebo neúspěchy ověřování certifikátů, aniž byste opravili příčinu.

Caution

Pokud se spojení během zápisu nebo potvrzení přeruší, klient nemusí vědět, zda SQL Server transakci pořídil. Slepě operaci neopakujte. Zkontrolujte výsledek nebo použijte aplikační návrh, který zabraňuje duplicitním efektům, než to zkusíte znovu.

Diagnostika a trasování

Shromážděte diagnostické informace v okamžiku selhání, než nesouvisející volání poskytovatele přepíšou informace o chybě.

Zaznamenejte operaci, která selhala, časové razítko a časové pásmo, uplynulý čas a HRESULT. Pro nativní uživatele OLE DB načítejte všechny dostupné záznamy skrze IErrorInfo a IErrorRecords, nejen první popis. Zahrňte SQLSTATE a nativní číslo chyby SQL Server, pokud je dostupné, přes ISQLErrorInfo. Vizte Načtení informací o chybě a Podrobnosti o chybě serveru SQL Server. Pro ADO zachyťte sbírku Errors spojení.
Shromažďujte stavy pro jednotlivé vlastnosti, vazby a hodnoty u metod, které chyby hlásí tímto způsobem. Nepřítomnost chybového objektu neznamená, že výsledek s částečným úspěchem lze bezpečně ignorovat.
Korelujte selhání klienta s logem chyb serveru nebo rozšířenými událostmi. Pokud je k dispozici, zaznamenejte ClientConnectionID a ActivityID. Selhání před předpřihlášením může nastat i bez identifikátoru klientského připojení.
Pokud chybové záznamy nestačí, použijte diagnostické informace Access v logu rozšířených událostí pro sledování ovladačů a nastavení korelace. Shromážděte omezený záznam trasování během reprodukce a poté trasování ukončete.

Při eskalaci zahrňte verzi ovladače, požadovaného poskytovatele, architekturu aplikací a procesů, verzi serveru, způsob autentizace, efektivní nastavení připojení, fázi selhání, chybové záznamy a minimální reprodukci. Uveďte, zda příslušný test UDL proběhl úspěšně a zda se problém týká jednoho hostitele, nebo více hostitelů.

Odstraňte hesla, přístupové tokeny a další tajemství z nastavení připojení a logů. Kontrolujte stopy pro dotazovací texty a citlivá data, ukládejte je s omezeným přístupem a sdílejte je pouze prostřednictvím schváleného kanálu podpory.

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-09-23