Programozási irányelvek

ODBC-illesztőprogram letöltése

Ez a cikk bemutatja a Linuxon vagy macOS-en futó SQL Serverhez készült Microsoft ODBC-illesztőprogramot használó alkalmazások programozási szempontjait. Néhány link az SQL Server Native Client anyagra utal. Ezek az oldalak korábbi API-kontextust adnak.

Illesztőprogram-verzió kiválasztása

Új fejlesztéshez használd a Microsoft ODBC Driver 18 for SQL Server-t, a jelenlegi illesztőprogram-családot. A Microsoft ODBC Driver 17 for SQL Server továbbra is támogatott azoknál az alkalmazásoknál, amelyek már használják azt, ahogy azt a támogatási életciklusban leírták. Az ODBC Driver 13, amely az SQL Server 2017-tel érkezett, csak egy kiterjesztett támogatási megállapodás keretében jogosult kiterjesztett támogatásra 2027. október 12-ig.

Adja meg a telepített illesztőprogram nevét a kapcsolati karakterláncben, kapcsos zárójelek közé téve:

Driver={ODBC Driver 18 for SQL Server}

Driver={ODBC Driver 17 for SQL Server}

Egy adatforrásnévben (DSN) a(z) odbc.ini elemben használd a nevet kapcsos zárójelek nélkül, például Driver = ODBC Driver 18 for SQL Server. A DSN szintaxisáról lásd: Kapcsolati sztring kulcsszavai és adatforrásnevek (DSN-ek).

A verzióspecifikus csatlakozási beállításokról lásd: Főverziók közötti különbségek. A támogatási dátumokért és az operációs rendszer kompatibilitásáért lásd: Támogatási életciklus és Rendszerkövetelmények.

Alkalmazás készítése

A fejlécfájlok helyével, a sorrenddel, a fordítóparancsokkal, a könyvtárnevekkel és egy C++-mintával kapcsolatban lásd a C- és C++-alkalmazások fejlesztése az ODBC-illesztőprogrammal és a Csatlakozás és lekérdezés C++ és ODBC használatával című témaköröket.

Egy ODBC alkalmazás használhat Több Aktív Eredményhalmazt (MARS) és más SQL Server-specifikus funkciókat az unixODBC fejlécek (sql.h, sqlext.h, sqltypes.h és sqlucode.h) után a(z) msodbcsql.h beillesztésével. Ugyanazokat a szimbolikus neveket használd az SQL Server-specifikus elemekhez, amelyeket a Windows ODBC-alkalmazásokban használsz.

Illesztőprogram-képességek keresése

Kezdje az ODBC Programozói referenciával a szabványos alkalmazásprogramozási felülethez (API). Ezután használd a jelenlegi illesztőprogram-dokumentációt az illesztő-specifikus viselkedéshez.

A Microsoft ODBC Driver for SQL Server áttekintése a dokumentációra hivatkozik. Az alábbi SQL Server Native Client cikkek API kontextust adnak azoknak az alkalmazásoknak, amelyek Linux és macOS rendszeren használják az illesztőprogramot:

Limitations

Az alábbi funkciókról Linux és macOS rendszeren futó ODBC illesztőprogramban nem lett ellenőrizve, hogy megfelelően működnek-e:

Nem támogatott szolgáltatások

Az alábbi funkciók nem elérhetők az ODBC driverben Linux és macOS rendszeren:

  • Elosztott tranzakciók a(z) SQL_ATTR_ENLIST_IN_DTC attribútumon keresztül. Az illesztőprogram támogatja az XA tranzakciókat a Microsoft Distributed Transaction Coordinator (DTC) segítségével. További információért lásd: XA-tranzakciók használata a DTC-vel.

  • Adatbázis-tükrözés.

  • FILESTREAM.

  • Az ODBC-illesztőprogram teljesítményének profilozása, valamint a SQLSetConnectAttr témakörben tárgyalt, teljesítménnyel kapcsolatos következő 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_QUERY_INTERVAL
    • SQL_COPT_SS_PERF_QUERY_LOG

  • SQLBrowseConnect 17.2-es verzió előtt.

  • C intervallumtípusok, mint például a(z) SQL_C_INTERVAL_YEAR_TO_MONTH, a Adattípus-azonosítók és leírók dokumentumban dokumentálva.

  • A(z) SQLSetConnectAttr attribútum SQL_CUR_USE_ODBC értéke: SQL_ATTR_ODBC_CURSORS.

Karakteradatok kezelése

Linuxon és macOS-en UTF-16 SQLWCHAR puffereket használj ODBC széles karakterű API-kkal a natív wchar_t típus helyett. A meghajtó interfész 16 bites kódegységeket használ.

Karakterkódolások

Az ODBC Driver 13 és 13.1 esetén a(z) SQLCHAR adatokhoz UTF-8-at kell használni. Ezek a verziók semmilyen más kódolást nem támogatnak.

Az ODBC Driver 17-től kezdve a(z) SQLCHAR adatokhoz támogatott karakterkészletek és kódolások a következők:

Megjegyzés:

A iconvglibc és musl közötti különbségek miatt ezen területi beállítások közül sok nem támogatott az Alpine Linuxon. További információért lásd: Funkcionális különbségek a glibc-től.

Név Description
UTF-8 Unicode
CP437 MS-DOS LATIN USA
CP850 MS-DOS Latin 1
CP874 Latin/thai
CP932 Japán (Windows kódlap, 932)
CP936 Egyszerűsített kínai, GBK
CP949 koreai (Windows-kódlap 949)
CP950 Hagyományos kínai, Big5
CP1250 Közép-európai
CP1251 Cirill ábécé
CP1252 Nyugat-európai
CP1253 Görög
CP1254 Török
CP1255 Héber nyelv
CP1256 Arab nyelv
CP1257 Balti
CP1258 Vietnami
ISO-8859-1 Latin-1
ISO-8859-2 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 Héber nyelv
ISO-8859-9 Török
ISO-8859-13 Latin-7
ISO-8859-15 Latin-9

Amikor csatlakozol, a meghajtó felismeri annak a folyamatnak az aktuális területi beállításait, amelybe betöltötték. Ha a területi beállítás valamelyik felsorolt kódolást használja, akkor a meghajtó ezt a kódolást használja a SQLCHAR (keskeny karakteres) adatokhoz. Ellenkező esetben alapértelmezett UTF-8-at használ. A folyamatok alapértelmezés szerint a C lokáléban indulnak, ami miatt az illesztőprogram alapértelmezés szerint UTF-8-at használ. Ha egy alkalmazásnak szüksége van valamelyik felsorolt kódolásra, a csatlakozás előtt hívja meg a(z) setlocale elemet. Add meg explicit módon a területi beállítást, vagy használj egy üres karakterláncot (például setlocale(LC_ALL, "")) a környezet területi beállításainak használatához.

Egy tipikus Linux vagy macOS környezetben, ahol a kódolás UTF-8, az ODBC Driver 17 felhasználói, akik 13-ról vagy 13.1-ről frissítenek, nem észlelnek különbségeket. Azoknak az alkalmazásoknak, amelyek a felsorolt nem UTF-8 kódolások valamelyikét a(z) setlocale elemen keresztül használják, ezt a kódolást kell használniuk az illesztőprogram felé és az illesztőprogramtól érkező adatokhoz az UTF-8 helyett.

Az adatokhoz a(z) SQLWCHAR UTF-16LE (little endian) kódolást kell használni.

Amikor bemeneti paramétereket kötünk meg SQLBindParameter használatával, ha egy egy bájtos karakteres SQL-típust ad meg, például SQL_VARCHAR, az illesztőprogram átalakítja a kliens kódolásból származó adatokat a szerveroldali kódolásra az adott paraméterhez. A kódolás a kollációtól függ; nem mindig az 1252-es kódlap. 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. A forráskódolásban szereplő, a célkódolásban nem ábrázolható karakterek kérdőjellé (?) alakulnak.

Az adatvesztés elkerülése érdekében a bemeneti paraméterek kötésekor adjon meg egy Unicode SQL karaktertípust, például SQL_WVARCHAR. Az illesztőprogram átalakítja az ügyfélkódolást UTF-16-ra, amely képes minden Unicode karaktert ábrázolni. A céloszlopnak vagy paraméternek Unicode típusnak (nchar, nvarchar vagy ntext) kell lennie, vagy olyan típusnak, amelynek rendezése vagy kódolása képes az összes eredeti forrásadatot reprezentálni. Kimeneti paraméterekhez megadj egy Unicode SQL típust, illetve egy Unicode C típust (SQL_C_WCHAR), amely miatt az illesztőprogram UTF-16-ként adja vissza az adatokat, vagy egy keskeny C típust, amelynek kliens kódolása képes a forrásadatot képviselni. Az UTF-8 mindig képes megjeleníteni ezeket az adatokat.

További információért a kollációkról és kódolásokról lásd: Collation and Unicode támogatás.

Vannak konverziós különbségek a Windows és a Linux vagy a macOS iconv verziók között:

  • A 1255-ös kódoldalnál a(z) 0xCA bájt 0x05BA UTF-16 kódpontra konvertálódik Windowson, valamint 0x00CA kódpontra macOS-en és Linuxon a(z) libiconv 1.15 előtti verzióin.
  • A 2003-as Big5/CP950-verzióval (BIG5-2003) nem rendelkező Linux iconv könyvtárak nem konvertálják helyesen az abban a verzióban hozzáadott karaktereket.
  • A 932-es kódoldal (japán, Shift-JIS) esetében a kódolási szabványban nem definiált karakterek dekódolása eltér. Például a byte 0x80 Windows-on U+0080-ra konvertálódik, és Linuxon és macOS-en U+30FB-vé válhat, a iconv verziótól függően.

Az ODBC Driver 13 és 13.1-ben az UTF-8-as többbájtos karakterek vagy UTF-16 helyettesítők a SQLPutData pufferek közötti szétosztása adatkorrupcióhoz vezet. Használj streaming puffereket, amelyek nem részleges karakterkódolású bájtokra végződnek. Ezt a korlátozást az ODBC Driver 17-ben eltávolították.

A karakterkódolással, átalakítással, paraméterkötéssel és pufferméretezéssel kapcsolatos útmutatásért lásd az Ismert problémák című részt.

OpenSSL

Az ODBC Driver 17.4-től kezdve az illesztőprogram dinamikusan tölti be az OpenSSL-t, ami lehetővé teszi, hogy olyan rendszereken fusson, amelyek 1.0 vagy 1.1 verzióval rendelkeznek, külön illesztőprogram-fájlok nélkül. 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 több OpenSSL verzió is jelen van, az illesztőprogram megpróbál betölteni egy támogatott verziót a könyvtárkereső útvonalakból.

Illesztőprogram verziója Támogatott OpenSSL-verziók
17,4-től 17,8-ig 1.0, 1.1
a 17.9-es és az azt követő 17.x verziók, valamint minden Driver 18 verzió 1.0, 1.1, 3.0

Az OpenSSL 4 nem támogatott. macOS-en egy Homebrew openssl link, amely az OpenSSL 4-re vezet, megakadályozhatja, hogy az illesztőprogram betöltse az OpenSSL-t, még akkor is, ha az OpenSSL 3 telepítve van. Nézd meg a könyvtári útvonalat és a telepített verziókat is.

Megjegyzés:

Lehetséges konfliktus akkor alakulhat ki, ha az illesztőprogramot használó alkalmazás vagy annak egyik komponense egy másik OpenSSL-verzióhoz kapcsolódik, vagy azt dinamikusan betölti. Ha több OpenSSL verzió is jelen van a rendszerben, és az alkalmazás használja, győződjön meg róla, hogy az alkalmazás által betöltött verzió és az illesztőprogram egyezzen meg. A hibák memóriaromlást okozhatnak, és nem feltétlenül jelennek meg nyilvánvaló vagy következetes módon.

Alpine Linux

Az musl új szálainak alapértelmezett stackmérete 128 KB, hacsak a futtatható fájl nem kér nagyobb alapértelmezést. Egy szál meghaladhatja ezt a határt, amikor meghívja a drivert. Kapcsoljon össze egy ODBC-alkalmazást Alpine Linuxon a -Wl,-z,stack-size=<size_in_bytes> használatával, hogy nagyobb alapértelmezett szálvermet kérjen. Azoknak az alkalmazásoknak, amelyek explicit stack mérettel hoznak létre szálakat, megfelelő méretet is ki kell választaniuk ezekhez a szálakhoz.

A fő szál stackje és az új szálak alapértelmezett stackje nem ugyanaz a beállítás. glibc rendszereken az új szálak alapértelmezett beállítása általában a folyamat veremerőforrás-korlátját követi, és ha ez korlátlan, architektúrafüggő tartalékértéket használ. Ne feltételezd, hogy minden Linux rendszeren fix 2 MB az alapértelmezett.

További megjegyzések

Ha dedikált adminisztrátori kapcsolatot (DAC) szeretnél létrehozni egy ODBC alkalmazásból, állítsd be a(z) Server=tcp:<server>,<dac_port> értéket a kapcsolati karakterláncban. Használd a felfedezett DAC portot, ne az instance normál csatlakozási portját. Például, ha a DAC port 33000, állítsd Server=tcp:<server>,33000 be. Ezek a kapcsolati karakterlánc töredékei csak a végpontot jelölik meg, nem a hitelesítést. Konfigurálja külön a hitelesítést és a szervertanúsítvány-ellenőrzést.

A bejelentkezési névnek a(z) sysadmin kiszolgálószerepkör tagjának kell lennie. A távoli hozzáféréshez engedélyezni kell a szerver távoli rendszergazdai kapcsolatok beállítását. Hozzáférési követelmények, szerver konfiguráció és parancssor-adminisztrációs eljárások esetén lásd: Diagnosztikai kapcsolat adatbázis-adminisztrátorok számára. Portfelderítésért lásd a DAC portot.

Az unixODBC driver manager ugyanúgy kezeli a SQLSetConnectAttr útján átadott utasításattribútumokat, mint a Windows Driver Manager. Az ODBC 2.x utasításopciók, mint például a SQL_ATTR_QUERY_TIMEOUT és a SQL_ATTR_MAX_ROWS, érvényesek a meglévő és új utasításokra a kapcsolaton. Az ODBC 3.x csak utasításokra vonatkozó attribútumok, például a SQL_ATTR_ROW_ARRAY_SIZE és a SQL_ATTR_PARAMSET_SIZE, az SQLSTATE HY092-t adják vissza. A kapcsolati és az utasításszinteken definiált attribútumok, például SQL_ATTR_METADATA_ID, bármelyik szinten beállíthatók. Az ODBC 3.x-ben elavult, hogy csak utasításszintű attribútumokat állítsanak be kapcsolati szinten, ezért inkább a(z) SQLSetStmtAttr hívást kell használni. További információért lásd: SQLSetConnectAttr függvény.

Erősen többszálú alkalmazásokban a unixODBC kezelő ellenőrzése teljesítménybeli szűk keresztmetszetté válhat. Az unixODBC fordítása --enable-fastvalidate használatával javíthatja a teljesítményt. Ez az opció azonban okozhatja, hogy azok az alkalmazások, amelyek érvénytelen fogantyúkat passzolnak az ODBC API-knak, összeomlanak ahelyett, hogy visszaadnák SQL_INVALID_HANDLE.

A platform telepítési és konfigurálási lépéseiért lásd:

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: