Udostępnij przez

Wytyczne dotyczące programowania

pobierz sterownika ODBC

Funkcje programowania sterownika Microsoft ODBC dla programu SQL Server w systemach macOS i Linux są oparte na odBC w programie SQL Server Native Client (SQL Server Native Client (ODBC)). Klient natywny programu SQL Server jest oparty na odBC w składnikach dostępu do danych systemu Windows (dokumentacja programisty ODBC).

Aplikacja ODBC może używać Multiple Active Result Sets (MARS) i innych funkcji specyficznych dla programu SQL Server, po włączeniu nagłówków /usr/local/include/msodbcsql.h unixODBC (sql.h, sqlext.h, sqltypes.h i sqlucode.h). Następnie użyj tych samych nazw symbolicznych dla elementów specyficznych dla programu SQL Server, które będą używane w aplikacjach ODBC systemu Windows.

Dostępne funkcje

Poniższe sekcje z dokumentacji klienta natywnego programu SQL Server dla odBC (SQL Server Native Client (ODBC)) są prawidłowe w przypadku używania sterownika ODBC w systemach macOS i Linux:

Nieobsługiwane funkcje

Następujące funkcje nie zostały zweryfikowane w celu poprawnego działania sterownika ODBC w systemach macOS i Linux:

Następujące funkcje nie są dostępne w sterowniku ODBC w systemach macOS i Linux:

  • Transakcje rozproszone (atrybut SQL_ATTR_ENLIST_IN_DTC nie jest obsługiwany)
  • Dublowanie bazy danych
  • FILESTREAM
  • Profilowanie wydajności sterowników ODBC omówione w artykule SQLSetConnectAttr oraz następujące atrybuty połączenia związane z wydajnością:
    • SQL_COPT_SS_PERF_DATA
    • SQL_COPT_SS_PERF_DATA_LOG
    • SQL_COPT_SS_PERF_DATA_LOG_NOW
    • SQL_COPT_SS_PERF_QUERY
    • SQL_COPT_SS_PERF_QUERY_INTERVAL
    • SQL_COPT_SS_PERF_QUERY_LOG
  • SQLBrowseConnect (przed wersją 17.2)
  • Typy interwałów języka C, takie jak SQL_C_INTERVAL_YEAR_TO_MONTH (udokumentowane w temacie Identyfikatory typów danych i deskryptory)
  • Wartość SQL_CUR_USE_ODBC dla atrybutu SQL_ATTR_ODBC_CURSORS funkcji SQLSetConnectAttr.

Obsługa zestawu znaków

W przypadku sterownika ODBC 13 i 13.1 dane SQLCHAR muszą być utF-8. Nie są obsługiwane żadne inne kodowanie.

W przypadku sterownika ODBC 17 obsługiwane są dane SQLCHAR w jednym z następujących zestawów znaków/kodowania:

Uwaga / Notatka

Ze względu na różnice w iconv oraz w musl i glibc wiele z tych ustawień regionalnych nie jest obsługiwanych w Alpine Linux.

Aby uzyskać więcej informacji, zobacz Różnice funkcjonalne w porównaniu do glibc

Name Description
UTF-8 Unicode
CP437 MS-DOS Latin US
CP850 MS-DOS łaciński 1
CP874 Łaciński/tajski
CP932 Japoński, Shift-JIS
CP936 Chiński uproszczony, GBK
CP949 Koreański, EUC-KR
CP950 Chiński tradycyjny, Big5
CP1251 Cyrylica
CP1253 Grecki
CP1256 Arabski język
CP1257 Bałtyckiego
CP1258 Wietnamski
ISO-8859-1 / CP1252 Latin-1
ISO-8859-2 / CP1250 Latyno-2
ISO-8859-3 Latyno-3
ISO-8859-4 Latyno-4
ISO-8859-5 Łaciński/cyrylica
ISO-8859-6 Łaciński/arabski
ISO-8859-7 Łaciński/grecki
ISO-8859-8 / CP1255 Hebrajski
ISO-8859-9 / CP1254 Turecki
ISO-8859-13 Latyno-7
ISO-8859-15 Latin-9

Po nawiązaniu połączenia sterownik wykrywa bieżące ustawienia regionalne procesu, w ramach których został załadowany. Jeśli używa jednego z powyższych kodowań, sterownik używa tego kodowania dla danych SQLCHAR (wąski znak). w przeciwnym razie wartość domyślna to UTF-8. Ponieważ wszystkie procesy są domyślnie uruchamiane w ustawieniach regionalnych "C" (i powodują, że sterownik domyślnie ma wartość UTF-8), jeśli aplikacja musi używać jednego z powyższych kodowań, należy użyć funkcji setlocale , aby odpowiednio ustawić ustawienia regionalne przed nawiązaniem połączenia; przez jawne określenie ustawień regionalnych lub użycie pustego ciągu na przykład setlocale(LC_ALL, "") do używania ustawień regionalnych środowiska.

W związku z tym w typowym środowisku systemu Linux lub macOS, w którym kodowanie to UTF-8, użytkownicy sterownika ODBC 17 uaktualnieni z wersji 13 lub 13.1 nie będą obserwować żadnych różnic. Jednak aplikacje wymienione na powyższej liście, które używają kodowania innego niż UTF-8 za pomocą setlocale(), muszą używać tego kodowania dla przesyłania danych do i ze sterownika zamiast UTF-8.

Dane typu SQLWCHAR muszą być w formacie UTF-16LE (Little Endian).

W przypadku powiązania parametrów wejściowych z parametrami SQLBindParameter, jeśli określono wąski typ SQL, taki jak SQL_VARCHAR, sterownik konwertuje podane dane z kodowania klienta na domyślne (zazwyczaj kodowanie strony kodowej 1252) programu SQL Server. W przypadku parametrów wyjściowych sterownik konwertuje kodowanie określone w informacjach sortowania skojarzonych z danymi do kodowania klienta. Jednak utrata danych jest możliwa --- znaki w kodowaniu źródłowym, które nie mogą być przedstawione w kodowaniu docelowym, zostaną zamienione na znak zapytania ('?').

Aby uniknąć tej utraty danych podczas wiązania parametrów wejściowych, określ typ znaków Unicode SQL, taki jak SQL_NVARCHAR. W takim przypadku sterownik konwertuje kodowanie klienta na UTF-16, co może reprezentować wszystkie znaki Unicode. Ponadto kolumna docelowa lub parametr na serwerze musi być również typem Unicode (nchar, nvarchar, ntext) lub jednym z sortowaniem/kodowaniem, który może reprezentować wszystkie znaki oryginalnych danych źródłowych. Aby uniknąć utraty danych z parametrami wyjściowymi, określ typ SQL Unicode i typ Unicode C (SQL_C_WCHAR), powodując, że sterownik zwraca dane jako UTF-16 lub wąski typ C i upewnij się, że kodowanie klienta może reprezentować wszystkie znaki danych źródłowych (ta reprezentacja jest zawsze możliwa w przypadku formatu UTF-8).

Aby uzyskać więcej informacji na temat sortowania i kodowania, zobacz Obsługa sortowania i unicode.

Istnieją pewne różnice w konwersji kodowania między systemem Windows i kilkoma wersjami biblioteki iconv w systemach Linux i macOS. Dane tekstowe na stronie kodowej 1255 (hebrajski) mają jeden punkt kodu (0xCA), który zachowuje się inaczej podczas konwersji na Unicode. W systemie Windows ten znak konwertuje na punkt kodu UTF-16 0x05BA. W systemach macOS i Linux z libiconv wersjami starszymi niż 1.15 jest konwertowany na 0x00CA. W systemie Linux z bibliotekami iconv, które nie obsługują rewizji 2003 Big5/CP950 (oznaczonej jako BIG5-2003), znaki dodane w tej rewizji nie będą poprawnie konwertowane. W kodzie 932 (japoński, Shift-JIS), wynik dekodowania znaków, które nie zostały pierwotnie zdefiniowane w standardzie kodowania, również się różni. Na przykład bajt 0x80 konwertuje na U+0080 w systemie Windows, ale może stać się U+30FB w systemach Linux i macOS, w zależności od wersji iconv.

W sterowniku ODBC 13 i 13.1, gdy znaki wielobajtowe UTF-8 lub pary zastępcze UTF-16 są dzielone między bufory SQLPutData, powoduje to uszkodzenie danych. Używaj buforów do strumieniowego przesyłania SQLPutData, które nie kończą się na kodowaniu częściowych znaków. To ograniczenie zostało usunięte z sterownika ODBC 17.

OpenSSL

Począwszy od wersji 17.4 sterownik ładuje dynamicznie bibliotekę OpenSSL, co pozwala na uruchamianie go w systemach, które mają wersję 1.0 lub 1.1 bez konieczności używania oddzielnych plików sterowników. Począwszy od wersji 17.9, sterownik obsługuje program OpenSSL 3.0 oprócz poprzednich wersji. Gdy istnieje wiele wersji biblioteki OpenSSL, sterownik podejmie próbę załadowania najnowszej wersji.

Wersja sterownika Obsługiwane wersje protokołu OpenSSL
17.4+ 1.0, 1.1
17.9, 18.0+ 1.0, 1.1, 3.0

Uwaga / Notatka

Potencjalny konflikt może wystąpić, jeśli aplikacja używająca sterownika (lub jednego z jego składników) jest połączona lub dynamicznie ładuje inną wersję biblioteki OpenSSL. Jeśli w systemie znajduje się kilka wersji biblioteki OpenSSL i używa jej aplikacja, zdecydowanie zaleca się, aby zachować szczególną ostrożność, upewniając się, że wersja załadowana przez aplikację i sterownik nie są niezgodne, ponieważ błędy mogą uszkodzić pamięć, a tym samym niekoniecznie będą manifestować się w oczywisty lub spójny sposób.

Alpine Linux

W momencie pisania tego zapisu domyślny rozmiar stosu w MUSL wynosi 128K, co jest wystarczające dla podstawowej funkcjonalności sterownika ODBC, jednak w zależności od tego, co aplikacja robi, nie jest trudno przekroczyć tego limitu, zwłaszcza podczas wywoływania sterownika z wielu wątków. Zaleca się, aby aplikacja ODBC w systemie Alpine Linux była kompilowana z -Wl,-z,stack-size=<VALUE IN BYTES> aby zwiększyć rozmiar stosu. Do celów referencyjnych domyślny rozmiar stosu w większości systemów GLIBC wynosi 2 MB.

Dodatkowe uwagi

  • Możesz utworzyć dedykowane połączenie administratora (DAC) przy użyciu uwierzytelniania SQL Server oraz hosta i portu. Członek roli Sysadmin musi najpierw odnaleźć port DAC. Zobacz Połączenie diagnostyczne dla administratorów bazy danych , aby dowiedzieć się, jak to zrobić. Jeśli na przykład port DAC miał wartość 33000, możesz nawiązać z nim połączenie w sqlcmd następujący sposób:

    sqlcmd -U <user> -P <pwd> -S <host>,33000

    Uwaga / Notatka

    Połączenia DAC muszą używać uwierzytelniania programu SQL Server.

  • Menedżer sterowników UnixODBC zwraca wartość "nieprawidłowy atrybut/identyfikator opcji" dla wszystkich atrybutów instrukcji, gdy są przekazywane przez element SQLSetConnectAttr. W systemie Windows, gdy SQLSetConnectAttr otrzymuje wartość atrybutu zapytania, powoduje, że sterownik ustawia tę wartość dla wszystkich aktywnych zapytań, które są elementami podrzędnymi uchwytu połączenia.

  • W przypadku korzystania ze sterownika z wysoce wielowątkowymi aplikacjami, walidacja uchwytów unixODBC może stać się wąskim gardłem wydajności. W takich scenariuszach można uzyskać wyższą wydajność przez skompilowanie unixODBC z opcją --enable-fastvalidate . Niemniej jednak, uważaj, ponieważ ta opcja może spowodować awarię aplikacji, które przekazują nieprawidłowe dojścia do interfejsów API ODBC, zamiast zwracać błędy SQL_INVALID_HANDLE.

Zobacz też

Często zadawane pytania
Znane Problemy w tej wersji sterownika
Notatki o wydaniu

  • Last updated on