Megosztás:

Programozási irányelvek

ODBC-illesztőprogram letöltése

A MacOS-en és Linuxon futó SQL Serverhez készült Microsoft ODBC-illesztőprogram programozási funkciói az SQL Server natív ügyfélprogramjában (SQL Server Native Client (ODBC) található ODBC-n alapulnak. Az SQL Server natív ügyfele az ODBC-n alapul a Windows Adatelérési összetevőkben (ODBC programozói referencia).

Az ODBC-alkalmazás a több aktív eredményhalmazt (MARS) és más SQL Server-specifikus szolgáltatásokat a unixODBC-fejlécek (sql.h, sqlext.h, sqltypes.h, sqlucode.h) felvétele után a /usr/local/include/msodbcsql.h használatával képes használni. Ezután használja ugyanazokat a szimbolikus neveket az SQL Server-specifikus elemekhez, amelyeket a Windows ODBC-alkalmazásokban használna.

Elérhető funkciók

Az ODBC-hez készült SQL Server natív ügyfél dokumentációjának (SQL Server Native Client (ODBC)) alábbi szakaszai érvényesek az ODBC-illesztőprogram macOS-en és Linuxon való használatakor:

Nem támogatott szolgáltatások

Az alábbi funkciók nem lettek ellenőrizve, hogy megfelelően működjenek az ODBC-illesztőben macOS és Linux rendszeren:

A következő funkciók nem érhetők el az ODBC-illesztőprogramban macOS és Linux rendszeren:

  • Elosztott tranzakciók (SQL_ATTR_ENLIST_IN_DTC attribútum nem támogatott)
  • Adatbázis-tükrözés
  • FILESTREAM
  • Az SQLSetConnectAttrben tárgyalt ODBC-illesztő teljesítményének profilozása és a következő teljesítményhez kapcsolódó kapcsolati attribútumok:
    • 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_LEKÉRDEZÉSI_IDŐKÖZ
    • SQL_COPT_SS_PERF_QUERY_LOG
  • SQLBrowseConnect (a 17.2-es verzió előtt)
  • C intervallumtípusok, például SQL_C_INTERVAL_YEAR_TO_MONTH ( adattípus-azonosítókban és leírókban dokumentálva)
  • Az SQLSetConnectAttr függvény SQL_ATTR_ODBC_CURSORS attribútumának SQL_CUR_USE_ODBC értéke.

Karakterkészlet támogatása

Az ODBC Driver 13 és 13.1 esetében az SQLCHAR-adatoknak UTF-8-nak kell lenniük. Más kódolások nem támogatottak.

Az ODBC Driver 17 esetében az SQLCHAR-adatok az alábbi karakterkészletek/kódolások egyikében támogatottak:

Megjegyzés:

Mivel az Alpesi Linux sok ilyen területi beállítást nem támogat a iconv közötti különbségek musl és glibc miatt.

További információ: A glibc funkcionális eltérései

Név Description
UTF-8 Unicode
CP437 MS-DOS LATIN USA
CP850 MS-DOS Latin 1
CP874 Latin/thai
CP932 Japán, Shift-JIS
CP936 Egyszerűsített kínai, GBK
CP949 Koreai, EUC-KR
CP950 Hagyományos kínai, Big5
CP1251 Cirill ábécé
CP1253 Görög
CP1256 Arab nyelv
CP1257 Balti
CP1258 Vietnami
ISO-8859-1 / CP1252 Latin-1
ISO-8859-2 / CP1250 Latin-2
ISO-8859-3 Latin-3
ISO-8859-4 Latin-4
ISO-8859-5 Latin/cirill betűs
ISO-8859-6 Latin/Arab
ISO-8859-7 Latin/görög
ISO-8859-8 / CP1255 Héber nyelv
ISO-8859-9 / CP1254 Török
ISO-8859-13 Latin-7
ISO-8859-15 Latin-9

Csatlakozáskor az illesztőprogram észleli a betöltött folyamat aktuális területi beállítását. Ha a fenti kódolások egyikét használja, az illesztőprogram ezt a kódolást használja az SQLCHAR (keskeny karakterű) adatokhoz; ellenkező esetben alapértelmezés szerint UTF-8 lesz. Mivel az összes folyamat alapértelmezés szerint a "C" területi beállításban kezdődik (és az illesztő alapértelmezett értéke UTF-8), ha egy alkalmazásnak a fenti kódolások egyikét kell használnia, a setlocale függvényt kell használnia a területi beállítás megfelelő beállításához a csatlakozás előtt; vagy a területi beállítás explicit megadásával, vagy egy üres sztring használatával, például setlocale(LC_ALL, "") a környezet területi beállításainak használatához.

Ezért egy tipikus Linux- vagy macOS-környezetben, ahol a kódolás UTF-8, az ODBC Driver 17 13-ról vagy 13.1-ről frissített felhasználói nem fognak különbséget tapasztalni. Azok az alkalmazások azonban, amelyek nem UTF-8 kódolást használnak a fenti listában setlocale() , az UTF-8 helyett ezt a kódolást kell használniuk az illesztőprogramba vagy az illesztőprogramból érkező adatokhoz.

Az SQLWCHAR-adatoknak UTF-16LE-nek (Little Endian) kell lenniük.

Ha a bemeneti paramétereket az SQLBindParameterrel köti, ha egy keskeny karakterű SQL-típus, például SQL_VARCHAR van megadva, az illesztő az ügyfélkódolásból származó adatokat az alapértelmezett (általában 1252-es kódlapú) SQL Server-kódolásra alakítja át. Kimeneti paraméterek esetén az illesztőprogram az adatokhoz társított rendezési információkban megadott kódolásból az ügyfél kódolására konvertál. Az adatvesztés azonban lehetséges, --- a forráskódolásban a célkódolásban nem ábrázolható karakterek kérdőjelké (?) alakulnak át.

Ha szeretné elkerülni ezt az adatvesztést a bemeneti paraméterek kötésekor, adjon meg egy Unicode SQL-karaktertípust, például SQL_NVARCHAR. Ebben az esetben az illesztőprogram UTF-16-ra konvertálja az ügyfélkódolást, amely az összes Unicode-karaktert képviselheti. Ezenkívül a kiszolgáló céloszlopának vagy paraméterének Unicode-típusnak (nchar, nvarchar, ntext) vagy rendezéssel/kódolással kell rendelkeznie, amely az eredeti forrásadatok összes karakterét képviselheti. Ha a kimeneti paraméterekkel szeretné elkerülni az adatvesztést, adjon meg Unicode SQL-típust és Unicode C-típust (SQL_C_WCHAR), amely miatt az illesztő UTF-16-ként vagy szűk C típusként adja vissza az adatokat, és győződjön meg arról, hogy az ügyfélkódolás a forrásadatok összes karakterét képviselheti (ez a reprezentáció mindig lehetséges az UTF-8 használatával).)

A rendezésről és a kódolásról további információt a Rendezés és a Unicode támogatása című témakörben talál.

A Windows és az iconv könyvtár több verziója között van néhány kódolási konverziós különbség Linuxon és macOS rendszeren. Az 1255-ös (héber) kódlap szöveges adatainak egyetlen kódpontja (0xCA) van, amely a Unicode-ra való átalakításkor eltérően viselkedik. Windows rendszeren ez a karakter 0x05BA UTF-16 kódpontjává alakul át. Az 1.15-nél korábbi libiconv verziójú macOS-en és Linuxon 0x00CA lesz. Azon ikonkódtárakkal rendelkező Linux rendszeren, amelyek nem támogatják a Big5/CP950 (elnevezett BIG5-2003) 2003-as változatát, a változathoz hozzáadott karakterek nem lesznek megfelelően konvertálva. A codepage 932 -ben (japán, Shift-JIS) a kódolási szabványban eredetileg nem definiált karakterek dekódolásának eredménye is eltér. A bájt 0x80 például U+0080-ra konvertál Windows rendszeren, de az ikonv verziójától függően U+30FB-né válhat Linuxon és macOS rendszeren.

Az ODBC Driver 13 és 13.1 esetében, ha az UTF-8 többbájtos karakterek vagy az UTF-16 helyettesítők fel vannak osztva az SQLPutData-pufferek között, az adatsérülést eredményez. Olyan puffereket használjon az SQLPutData streameléséhez, amelyek nem részleges karakterkódolásokkal végződnek. Ezt a korlátozást az ODBC Driver 17 eltávolította.

OpenSSL

A 17.4-es verziótól kezdve az illesztőprogram dinamikusan betölti az OpenSSL-t, ami lehetővé teszi, hogy az 1.0-s vagy az 1.1-es verziójú rendszereken fusson anélkül, hogy külön illesztőprogram-fájlokra lenne szükség. A 17.9-es verziótól kezdve az illesztőprogram az előző verziók mellett az OpenSSL 3.0-t is támogatja. Ha az OpenSSL több verziója is jelen van, az illesztőprogram megpróbálja betölteni a legújabbat.

Illesztőprogram verziója Támogatott OpenSSL-verziók
17.4+ 1.0, 1.1
17.9, 18.0+ 1.0, 1.1, 3.0

Megjegyzés:

Lehetséges ütközés akkor fordulhat elő, ha az illesztőprogramot (vagy annak egyik összetevőjét) használó alkalmazás az OpenSSL egy másik verziójával van összekapcsolva vagy dinamikusan betöltve. Ha az OpenSSL több verziója is jelen van a rendszeren, és az alkalmazás használja azt, javasoljuk, hogy fokozott óvatossággal gondoskodjon arról, hogy az alkalmazás és az illesztőprogram által betöltött verzió ne összhangban legyen, mivel a hibák megsérülhetnek a memóriában, és így nem feltétlenül nyilvánvaló vagy konzisztens módon fognak megnyilvánulni.

Alpine Linux

Az íráskor a MUSL alapértelmezett veremmérete 128K, ami elegendő az ALAPVETŐ ODBC-illesztőprogram-funkciókhoz, azonban attól függően, hogy az alkalmazás mit tesz, nem nehéz túllépni ezt a korlátot, különösen akkor, ha több szálból hívja meg az illesztőprogramot. Javasoljuk, hogy az Alpine Linuxon egy ODBC-alkalmazást állítson össze -Wl,-z,stack-size=<VALUE IN BYTES> a verem méretének növelése érdekében. A legtöbb GLIBC-rendszerben az alapértelmezett veremméret 2 MB.

További megjegyzések

  • Dedikált rendszergazdai kapcsolatot (DAC) hozhat létre SQL Server-hitelesítéssel és a gazdagép, port megadásával. A Sysadmin szerepkör egyik tagjának először fel kell derítenie a DAC-portot. Tekintse meg az adatbázis-rendszergazdák diagnosztikai kapcsolatát , és ismerje meg, hogyan. Ha például a DAC-port 33000, az alábbi módon csatlakozhat hozzá: sqlcmd

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

    Megjegyzés:

    A DAC-kapcsolatoknak SQL Server-hitelesítést kell használniuk.

  • A UnixODBC illesztőprogram-kezelő "érvénytelen attribútumot/beállításazonosítót" ad vissza az összes utasításattribútumhoz az SQLSetConnectAttr szolgáltatáson keresztüli továbbításkor. Windows rendszeren, amikor az SQLSetConnectAttr lekérdezési attribútumértéket fogad, az meghajtó beállítja ezt az értéket az összes aktív lekérdezésen, amelyek a kapcsolati leíró gyermekei.

  • Ha az illesztőprogramot erősen többszálú alkalmazásokkal használja, a UnixODBC fogópont-ellenőrzése teljesítménybeli szűk keresztmetszetté válhat. Ilyen esetekben nagyobb teljesítmény érhető el, ha a unixODBC-t a --enable-fastvalidate opcióval fordítjuk. Azonban ügyeljen arra, hogy ez a beállítás azt eredményezheti, hogy az ODBC API-knak érvénytelen leírókat átadó alkalmazások összeomlanak, ahelyett, hogy hibákat SQL_INVALID_HANDLE adnak vissza.

Lásd még:

Gyakori kérdések
Illesztőprogram jelen verziójának ismert problémái
Kibocsátási megjegyzések

  • Last updated on