Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)
Po przydzieleniu środowiska i obsługi połączeń oraz ustawieniu atrybutów połączenia, aplikacja łączy się ze źródłem danych lub sterownikiem. Istnieją trzy funkcje, które możesz wykorzystać do połączenia:
Sqlconnect
Sqldriverconnect
Sqlbrowseconnect
Aby uzyskać więcej informacji o tworzeniu połączeń ze źródłem danych, w tym o dostępnych opcjach parametry połączenia, zobacz Using Connection String Keywords with SQL Server Native Client.
SQLConnect
SQLConnect to najprostsza funkcja połączenia. Akceptuje trzy parametry: nazwę źródła danych, identyfikator użytkownika oraz hasło. Używaj SQLConnect , gdy te trzy parametry zawierają wszystkie informacje potrzebne do połączenia z bazą danych. Aby to zrobić, zbuduj listę źródeł danych za pomocą SQLDataSources; poprosić użytkownika o podanie źródła danych, identyfikatora użytkownika i hasła; a potem zadzwonić do SQLConnect.
SQLConnect zakłada, że nazwa źródła danych, identyfikator użytkownika i hasło wystarczą do połączenia ze źródłem danych, a źródło danych ODBC zawiera wszystkie inne informacje potrzebne sterownikowi ODBC do nawiązania połączenia. W przeciwieństwie do SQLDriverConnect i SQLBrowseConnect, SQLConnect nie używa parametry połączenia.
SQLDriverConnect
SQLDriverConnect jest używany, gdy potrzebne są więcej informacji niż tylko nazwa źródła danych, identyfikator użytkownika i hasło. Jednym z parametrów SQLDriverConnect jest parametry połączenia zawierający informacje specyficzne dla sterownika. Możesz użyć SQLDriverConnect zamiast SQLConnect z następujących powodów:
Aby określić informacje specyficzne dla sterownika podczas połączenia łączności.
Aby poprosić sterownika, aby użytkownik podał informacje o połączeniu.
Aby łączyć się bez użycia źródła danych ODBC.
parametry połączenia SQLDriverConnect zawiera serię par słów klucz-wartość, które określają wszystkie informacje o połączeniu obsługiwane przez sterownik ODBC. Każdy sterownik obsługuje standardowe słowa kluczowe ODBC (DSN, FILEDSN, DRIVER, UID, PWD i SAVEFILE) oprócz specyficznych dla sterownika słów kluczowych dla wszystkich informacji o połączeniach obsługiwanych przez ten sterownik. SQLDriverConnect można używać do łączenia bez dostępu do źródła danych. Na przykład aplikacja zaprojektowana do połączenia "bez DSN" z instancją SQL Server może wywołać SQLDriverConnect za pomocą parametry połączenia definiującego identyfikator logowania, hasło, bibliotekę sieciową, nazwę serwera do połączenia oraz domyślną bazę danych do użycia.
Korzystając z SQLDriverConnect, istnieją dwie opcje ppytania użytkownika o potrzebne informacje o połączeniu:
Okno dialogowe aplikacji
Możesz stworzyć okno dialogowe aplikacji, które prosi o informacje o połączeniu, a następnie wywoła SQLDriverConnect z uchwytem okna NULL i ustawieniem DriverCompletion na SQL_DRIVER_NOPROMPT. Te ustawienia parametrów uniemożliwiają sterownikowi ODBC otwarcie własnego okna dialogowego. Metoda ta jest stosowana, gdy ważne jest sterowanie interfejsem użytkownika aplikacji.
Okno dialogowe sterowników
Możesz zakodować aplikację tak, aby przekazała poprawny uchwyt okna do SQLDriverConnect i ustawiła parametr DriverCompletion na SQL_DRIVER_COMPLETE, SQL_DRIVER_PROMPT lub SQL_DRIVER_COMPLETE_REQUIRED. Następnie sterownik generuje okno dialogowe, które prosi użytkownika o informacje o połączeniu. Ta metoda upraszcza kod aplikacji.
SQLBrowseConnect
SqlBrowseConnect, na przykład SQLDriverConnect, używa parametrów połączenia. Jednak korzystając z SQLBrowseConnect, aplikacja może iteracyjnie stworzyć kompletny parametry połączenia ze źródłem danych w czasie działania. Dzięki temu aplikacja może wykonywać dwie czynności:
Zbuduj własne okna dialogowe, które będą podpowiadać o te informacje, zachowując tym samym kontrolę nad interfejsem użytkownika.
Przeglądaj system w poszukiwaniu źródeł danych, które mogą zostać wykorzystane przez określony sterownik, prawdopodobnie w kilku krokach.
Na przykład użytkownik może najpierw przeglądać sieć serwerów i po wybraniu serwera przeglądać serwer pod kątem baz danych dostępnych przez sterownik.
Gdy SQLBrowseConnect zakończy pomyślne połączenie, zwraca parametry połączenia, który może być użyty przy kolejnych wywołaniach do SQLDriverConnect.
SQL Server sterownik ODBC natywnego klienta zawsze zwraca SQL_SUCCESS_WITH_INFO po udanym SQLConnect, SQLDriverConnect lub SQLBrowseConnect. Gdy aplikacja ODBC wywołuje SQLGetDiagRec po otrzymaniu SQL_SUCCESS_WITH_INFO, może otrzymać następujące komunikaty:
5701
Oznacza, że SQL Server umieścił kontekst użytkownika w domyślnej bazie danych zdefiniowanej w źródle danych lub w domyślnej bazie zdefiniowanej dla identyfikatora logowania używanego w połączeniu, jeśli źródło danych nie miało domyślnej bazy danych.
5703
Wskazuje język używany na serwerze.
Poniższy przykład pokazuje komunikat zwracany przez administratora systemu po udanym połączeniu:
szSqlState = "01000", *pfNativeError = 5701,
szErrorMsg="[Microsoft][SQL Server Native Client][SQL Server]
Changed database context to 'pubs'."
szSqlState = "01000", *pfNativeError = 5703,
szErrorMsg="[Microsoft][SQL Server Native Client][SQL Server]
Changed language setting to 'us_english'."
Możesz zignorować wiadomości 5701 i 5703; Są tylko informacyjne. Nie powinieneś jednak ignorować kodu zwrotnego SQL_SUCCESS_WITH_INFO, ponieważ mogą zostać zwrócone wiadomości inne niż 5701 lub 5703. Na przykład, jeśli sterownik łączy się z serwerem uruchamiającym instancję SQL Server z przestarzałymi procedurami katalogowymi, jednym z błędów zwracanych przez SQLGetDiagRec po SQL_SUCCESS_WITH_INFO jest:
SqlState: 01000
pfNative: 0
szErrorMsg: "[Microsoft][SQL Server Native Client]The ODBC
catalog stored procedures installed on server
my65server are version 06.50.0193; version 07.00.0205
or later is required to ensure proper operation.
Please contact your system administrator."
Funkcja obsługi błędów aplikacji dla SQL Server połączeń powinna wywoływać SQLGetDiagRec, aż zwróci SQL_NO_DATA. Powinien wtedy reagować na wszelkie wiadomości inne niż te z kodem pfNative 5701 lub 5703.