Rozwiązywanie problemów z Microsoft OLE DB Driver for SQL Server

Dotyczy:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSQL database w usłudze Microsoft Fabric

Użyj tego artykułu, aby zidentyfikować etap awarii operacji OLE DB, wybrać kolejną kontrolę i znaleźć szczegółowe instrukcje dotyczące rozwiązywania problemów. Wytyczne korzystają z obecnego dostawcy, MSOLEDBSQL19. Aby uzyskać informacje o błędach specyficznych dla danej wersji i zmianach związanych z aktualizacją, zobacz Znane problemy i Główne różnice między wersjami.

Zidentyfikuj objaw

Przed zmianą ustawień zrób pełny opis błędu oraz wszystkie dostępne rekordy błędów. Poziom najwyższy HRESULT, taki jak DB_E_ERRORSOCCURRED, sam w sobie nie identyfikuje przyczyny. Zarejestruj, czy awaria występuje podczas ładowania dostawcy, otwierania połączenia, wykonywania polecenia, pobierania danych lub zatwierdzania transakcji.

W przypadku awarii połączenia porównaj aplikację z testem połączenia Universal Data Link (UDL). Używaj tego samego komputera, dostawcy, architektury procesu, tożsamości uwierzytelniania, serwera, bazy danych oraz ustawień szyfrowania. Udany test z użyciem innego dostawcy lub innej tożsamości nie dowodzi, że konfiguracja aplikacji działa poprawnie.

Rejestracja dostawcy i architektura

Błędy takie jak Nie można znaleźć dostawcy lub REGDB_E_CLASSNOTREG (0x80040154, Klasa niezarejestrowana) wskazują, że dostawca jest ładowany przed uwierzytelnieniem w SQL Server.

1. Sprawdź dostawcę, którego żąda aplikacja. MSOLEDBSQL19 i MSOLEDBSQL identyfikują różne główne wersje. Zainstalowanie aktualnego sterownika nie zmienia wyboru dostawcy aplikacji. Postępuj zgodnie z krokami migracji , jeśli aplikacja nadal wymaga innego dostawcy.
2. Sprawdź architekturę procesu, który hostuje aplikację. Aplikacja 32-bitowa potrzebuje dostawcy 32-bitowego, nawet na 64-bitowym Windows. Dla usługi lub zaplanowanego zadania sprawdź plik wykonywalny i konto używane przez tego hosta, a nie tylko środowisko programistyczne.
3. Zainstaluj lub napraw sterownik za pomocą obsługiwanego instalatora na komputerze, na którym działa aplikacja. Instalator x64 zawiera zarówno 64-bitowe, jak i 32-bitowe pliki binarne sterowników. Sprawdź wymagane zależności w Install the OLE DB Driver and System requirements. Nie kopiuj bibliotek sterowników z innego komputera jako substytut instalacji.
4. Powtórz test UDL z dopasowaną architekturą i dostawcą. Jeśli działa, ale aplikacja nadal nie może załadować dostawcy, porównaj efektywny wybór dostawcy i architekturę hosta z testem.

Jeśli błąd wyraźnie wskazuje adal.dll, sprawdź znany problem z biblioteką uwierzytelniania, zamiast traktować go jako brak dostawcy SQL Server.

Niepowodzenia logowania i uwierzytelniania

Odróżnić odrzucenie logowania serwera od niepowodzenia w uzyskaniu danych uwierzytelniających lub nawiązaniu zaszyfrowanego połączenia. Przeczytaj pełny tekst błędu, w tym ewentualny błąd zagnieżdżonego dostawcy.

1. W przypadku błędu SQL Server 18456 poproś administratora bazy danych o sprawdzenie odpowiedniego wpisu w dzienniku błędów serwera oraz odpowiadającego mu stanu. Sprawdź tryb uwierzytelniania, status logowania, żądaną bazę danych oraz dostęp do bazy danych za pomocą MSSQLSERVER_18456. Nie zakładaj, że każde odrzucenie logowania oznacza błędne hasło.
2. W przypadku uwierzytelniania zintegrowanego potwierdź tożsamość, pod którą działa aplikacja. Konto serwisowe lub konto z zadaniami zaplanowanymi może różnić się od konta użytkownika, który pomyślnie przetestował połączenie. Jeśli komunikat zawiera Nie można wygenerować kontekstu SSPI, postępuj zgodnie z rozwiązywaniem problemów w interfejsie Security Support Provider Interface (SSPI) oraz wsparciem dotyczącym nazwy głównej usługi (SPN).
3. Dla Microsoft Entra ID sprawdź, czy wybrana metoda uwierzytelniania pasuje do środowiska wykonawczego aplikacji oraz czy jej tożsamość ma dostęp do docelowej bazy danych. Przejrzyj specyficzne dla metody ustawienia i ograniczenia tokenów dostępu w Use Microsoft Entra ID. Nie łącz tokena dostępu z kolidującymi właściwościami uwierzytelniania lub poświadczenia.
4. Porównaj efektywne ustawienia z właściwą tabelą słów kluczowych parametry połączenia. IDBInitialize::Initialize, IDataInitialize::GetDataSource, oraz ActiveX Data Objects (ADO) używają różnych tabel słów kluczowych. Sprawdź tabelę, aby zobaczyć interfejs, z którego korzysta twoja aplikacja.

Tekst Docelowa nazwa principal jest nieprawidłowa może pojawiać się w różnych kontekstach. Jeśli towarzyszy temu komunikat Nie można wygenerować kontekstu SSPI, sprawdź uwierzytelnianie systemu Windows i nazwy SPN. Jeśli błąd dotyczy certyfikatu lub uzgadniania szyfrowania, użyj następnej sekcji.

Awarie certyfikatów TLS

Błędy bezpieczeństwa warstwy transportowej (TLS) mogą wystąpić zanim zalogowanie dotrze do SQL Server. Obecny sterownik domyślnie umożliwia obowiązkowe szyfrowanie, więc aktualizacja może ujawnić problem z zaufaniem lub nazwą certyfikatu, którego starsza konfiguracja połączenia nie wykryła.

1. W przypadku łańcucha certyfikatów, który został wystawiony przez niezaufany urząd, sprawdź certyfikat przedstawiany przez program SQL Server oraz łańcuch certyfikatów urzędu wystawiającego, któremu ufa komputer kliencki. Skonfiguruj ważny certyfikat serwera i zainstaluj wymagane zaufane certyfikaty root i pośrednie poprzez proces zarządzania certyfikatami w Twojej organizacji.
2. W przypadku niezgodności nazw certyfikatu porównaj nazwę serwera lub słuchacza, której używa aplikacja, z nazwami zawartymi w certyfikcie. Użyj certyfikatu, który obejmuje zamierzoną nazwę połączenia. Jeśli aplikacja celowo używa innej nazwy połączenia, przed skonfigurowaniem oczekiwanej nazwy certyfikatu przejrzyj udokumentowaną właściwość HostNameInCertificate .
3. Sprawdź skuteczne ustawienia szyfrowania i walidacji, w tym ustawienia rejestru. Przejrzyj tabele szyfrowania i walidacji certyfikatów pod kątem precedencji i Strict zachowania. W Strict trybie sterownik waliduje certyfikat niezależnie od ustawienia trust-server-certificate.
4. Jeśli problem wystąpił podczas migracji, sprawdź rozwiązywanie problemów związanych z wersją główną, w tym typ wartości właściwości szyfrowania oraz ograniczenie dotyczące używania ServerCertificate poza trybem Strict.

Aby przeprowadzić szczegółowe kontrole, skorzystaj z Wymagania dotyczące certyfikatów dla programu SQL Server oraz Rozwiązywanie problemów z niezaufanym łańcuchem certyfikatów. Zachowaj szyfrowanie i walidację certyfikatów włączone w produkcji. Wyłączenie któregokolwiek z tych rozwiązań nie rozwiąże problemu z wdrożeniem certyfikatów.

Niepowodzenia wykrywania sieci i instancji

W przypadku serwera nieznalezionego, błędów lokalizujących serwer/instancję lub błędów odmowy połączenia – zidentyfikuj punkt końcowy, do którego aplikacja próbuje dotrzeć.

1. Zweryfikowaj nazwę serwera, nazwę instancji oraz skonfigurowany port nasłuchu z administratorem bazy danych. Potwierdź, że usługa bazy danych działa oraz że zamierzony protokół i słuchacz są włączone. Nie zakładaj, że każda instancja słucha na porcie 1433.
2. Dla zdalnego połączenia protokołu sterowania transmisją (TCP) testuj znany punkt końcowy, używając formatu nazwy serwera sterownika tcp:<server>,<port> . Zachowuj te same ustawienia uwierzytelniania, bazy danych i szyfrowania. Zobacz słowa kluczowe parametrów połączenia, aby znaleźć słowo kluczowe serwera odpowiednie dla używanego interfejsu.
3. Jeśli host i port podane jawnie działają, ale instancja nazwana nie, sprawdź usługę SQL Server Browser oraz wykrywanie instancji. Sprawdź usługę przeglądarki oraz ścieżkę portu 1434 protokołu User Datagram (UDP), gdzie wykorzystywane jest wykrywanie przeglądarki.
4. Jeśli punkt końcowy również zawiódł, sprawdź rozdzielczość systemu nazw domen (DNS), routing oraz dostęp firewall do faktycznego portu nasłuchującego z hosta aplikacji. Postępuj zgodnie z informacjami w sekcji Błędy połączenia związane z siecią lub specyficzne dla wystąpienia, zamiast zmieniać kilka ustawień połączenia naraz.

Jeśli chcesz słuchać w grupie dostępności, zapoznaj się także z wsparciem High availability i powrotem po awarii. W przypadku LocalDB użyj wsparcia dla LocalDB , aby sprawdzić lokalną instancję i kontekst użytkownika, zamiast stosować zdalne kroki wykrywania TCP.

Błędy w konwersji parametrów i danych

Jeśli połączenie się otworzy, ale wykonanie polecenia lub pobieranie danych nie powiodnie, ogranicz reprodukcję do uszkodzonego polecenia i wartości. Zachowaj oryginalny typ danych, długość, status null oraz kodowanie znaków podczas wymiany wrażliwych danych.

1. Porównaj każdy znacznik parametru ? z jego pozycją powiązania, kierunkiem i metadanymi. Gdy używasz ICommandWithParameters::SetParameterInfo, dopasuj typ źródłowy SQL do polecenia lub procedury przechowywanej. Nie zakładaj, że metadane parametrów są zawsze pobierane automatycznie. Przejrzyj parametry poleceń pod kątem ograniczeń wyprowadzania i zachowania parametrów wyjściowych.
2. Sprawdź statusy powiązania akcesorów oraz status i długość każdej zwróconej wartości, a nie tylko ogólne HRESULT. W przypadku błędów podczas ustawiania właściwości sprawdź element dwStatus każdej właściwości. Zwrócenie częściowego sukcesu, takie jak DB_S_ERRORSOCCURRED, może wymagać sprawdzenia tablicy stanów nawet wtedy, gdy obiekt błędu nie jest dostępny. Zobacz kody powrotu.
3. Dla konwersji lub obcięcia porównaj typ i rozmiar bufora konsumenckiego z rzeczywistymi metadanymi kolumny lub parametrów. Sprawdź precyzję i skalę dla wartości numerycznych, prawidłowe zakresy i ułamki sekund dla wartości dat/czasu oraz długości bajtów dla buforów znaków. Zbadaj DBSTATUS_E_CANTCONVERTVALUE, i nie traktuj DBSTATUS_S_TRUNCATED jako kompletnej wartości. Użyj Mapowania typów danych, Pobierania wierszy oraz Konwersji daty i godziny zgodnie z odpowiednimi zasadami.
4. Jeśli wydaje się, że brakuje powiązanych parametrów wyjściowych, przed ich odczytaniem przetwórz wszystkie zwrócone zestawy wierszy. Postępuj zgodnie z artykułem Używanie IMultipleResults do przetwarzania wielu zestawów wyników. W przypadku parametrów wyjściowych przesyłanych strumieniowo odczytaj lub zwolnij oczekujące strumienie przed zażądaniem kolejnego wyniku, jak opisano w sekcji Obsługa przesyłania strumieniowego dla parametrów wyjściowych.

W przypadku mapowań specyficznych dla ADO, zapoznaj się z Use ADO with the OLE DB Driver oraz ograniczeniami uwierzytelniania w DataTypeCompatibilityUse Microsoft Entra ID. Nie dodawaj ustawień kompatybilności bez sprawdzenia obu.

W przypadku uszkodzonych, wąskich ciągów w kolumnie sql_variant po aktualizacji sterownika przed modyfikacją przechowywanych danych przejrzyj istniejące znane problemy i procedurę odzyskiwania SSVARIANT .

Utrata połączenia i przerwy czasowe

Zapisuj, kiedy ostatnio połączenie działało, która operacja się nie powiodła i jak długo trwała. Rozróżnij te przypadki przed zmianą ustawień powtórki lub limitu czasu.

Odporność na połączenie bezczynne nie zapewnia powtórek połączenia na początku ani automatycznego odtwarzania dowolnych poleceń i transakcji. W przypadku potwierdzonej porażki przejściowej używaj ograniczonych prób aplikacji z opóźnieniem i rejestruj każdą próbę. Nie powtarzaj wielokrotnie błędów ładowania dostawców, odrzuconych poświadczeń czy błędów walidacji certyfikatów bez korekty przyczyny.

Diagnostyka i śledzenie

Zbieraj diagnostykę w miejscu awarii, zanim niepowiązane połączenia dostawcy zastąpią informacje o błędzie.

1. Zarejestruj operację, która zakończyła się błędem, znacznik czasu i strefę czasową, czas trwania oraz HRESULT. Dla natywnych konsumentów OLE DB, pobierz wszystkie dostępne rekordy za pomocą IErrorInfo i IErrorRecords, a nie tylko pierwszy opis. Dołącz SQLSTATE oraz natywny numer błędu SQL Server, jeśli jest dostępny za pośrednictwem ISQLErrorInfo. Zobacz informacje o błędach pobierania orazszczegóły błędów SQL Server. Dla ADO przechwyć kolekcję połączenia Errors .
2. Zbieraj statusy dla poszczególnych właściwości, powiązań i wartości dla metod, które w ten sposób raportują błędy. Brak obiektu błędu nie sprawia, że wynik częściowego sukcesu jest bezpieczny do zignorowania.
3. Powiązać awarię klienta z logiem błędów serwera lub rozszerzonymi zdarzeniami. Jeśli są dostępne, rejestruj ClientConnectionID i ActivityID. Awaria przed zalogowaniem może wystąpić bez identyfikatora połączenia klienta.
4. Jeśli zapisy błędów nie wystarczą, użyj informacji diagnostycznych Access w dzienniku Extended Events do śledzenia sterowników i konfiguracji korelacji. Zbierz ograniczony ślad wokół reprodukcji i przestań potem odznaczać.

Podczas eskalacji uwzględnij wersję sterownika, żądanego dostawcę, architekturę aplikacji i procesu, wersję serwera, metodę uwierzytelniania, efektywne ustawienia połączenia, etap awarii, rekordy błędów oraz minimalne odtworzenie. Określ, czy test dopasowania UDL się powiódł i czy problem dotyczy jednego hosta, czy wielu hostów.

Usuń hasła, tokeny dostępu i inne sekrety z ustawień połączenia i logów. Przeglądaj ślady pod kątem tekstów zapytań i wrażliwych danych, przechowuj je z ograniczonym dostępem i udostępniaj wyłącznie przez zatwierdzony kanał wsparcia.

Treści powiązane

• Szybki start: nawiązywanie połączenia i wykonywanie zapytań za pomocą sterownika Microsoft OLE DB
• Znane problemy
• Informacje o wydaniu
• Przegląd problemów z łącznością SQL Server