Riktlinjer för programmering

Ladda ned ODBC-drivrutins

Denna artikel beskriver programmeringsöverväganden för applikationer som använder Microsoft ODBC-drivrutinen för SQL Server on Linux eller macOS. Vissa länkar pekar på material från SQL Server Native Client. Dessa sidor ger historisk API-kontext.

Välj en drivrutinsversion

Använd Microsoft ODBC Driver 18 för SQL Server, den nuvarande drivrutinslinjen, för ny utveckling. Microsoft ODBC Driver 17 för SQL Server stöds fortfarande för applikationer som redan distribuerar det, enligt beskrivningen i supportlivscykeln. ODBC Driver 13, som levererades med SQL Server 2017, är berättigad till utökat stöd fram till den 12 oktober 2027, endast under ett förlängt supportavtal.

Ange namnet på den installerade drivrutinen i din anslutningssträng, omgivet av klammerparenteser:

Driver={ODBC Driver 18 for SQL Server}
Driver={ODBC Driver 17 for SQL Server}

I ett datakällnamn (DSN) i odbc.ini, använd namnet utan klammer, till exempel Driver = ODBC Driver 18 for SQL Server. För DSN-syntax, se Connection string keywords and data source names (DSNs).

För versionsspecifika anslutningsinställningar, se Stora versionsskillnader. För supportdatum och operativsystemkompatibilitet, se Supportlivscykel och Systemkrav.

Bygg en app

För header-placeringar, inkluderingsordning, kompilatorkommandon, biblioteksnamn och ett C++-exempel, se Utveckla C- och C++-applikationer med ODBC-drivrutinen och Anslut och fråga med C++ och ODBC.

En ODBC-applikation kan använda Multiple Active Result Sets (MARS) och andra SQL Server-specifika funktioner genom att lägga till msodbcsql.h efter unixODBC-huvuden (sql.h, sqlext.h, sqltypes.h, och sqlucode.h). Använd samma symboliska namn för SQL Server-specifika objekt som du använder i Windows ODBC-applikationer.

Identifiera drivrutinens funktioner

Börja med ODBC Programmer's Reference för det standardiserade applikationsprogrammeringsgränssnittet (API). Använd sedan den aktuella drivrutinsdokumentationen för drivrutinsspecifikt beteende.

Översikten över Microsoft ODBC Driver for SQL Server länkar till drivrutinsdokumentationen. Följande artiklar om SQL Server Native Client ger API-kontext för applikationer som använder drivrutinen på Linux och macOS:

Limitations

Följande funktioner har inte verifierats fungera korrekt i ODBC-drivrutinen på Linux och macOS:

Funktioner som inte stöds

Följande funktioner finns inte tillgängliga i ODBC-drivrutinen på Linux och macOS:

  • Distribuerade transaktioner via attributet SQL_ATTR_ENLIST_IN_DTC . Drivrutinen stöder XA-transaktioner via Microsoft Distributed Transaction Coordinator (DTC). För mer information, se Använd XA-transaktioner med DTC.

  • Databasspegling.

  • FILESTREAM.

  • Profilering av ODBC-drivrutinsprestanda, som diskuteras i SQLSetConnectAttr, och dessa prestandarelaterade anslutningsattribut:

    • 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 före version 17.2.

  • C-intervalltyper såsom SQL_C_INTERVAL_YEAR_TO_MONTH dokumenteras i Data Type Identifiers and Descriptors.

  • Värdet för attributet SQL_ATTR_ODBC_CURSORS i SQLSetConnectAttr.

Hantera teckendata

På Linux och macOS använder man UTF-16-buffertar SQLWCHAR med ODBC-bredtecken-API:er istället för den naturliga typen wchar_t. Drivrutinsgränssnittet använder 16-bitars kodenheter.

Teckenkodningar

För ODBC Driver 13 och 13.1 måste du använda UTF-8 för SQLCHAR data. Dessa versioner stöder inga andra kodningar.

Från och med ODBC Driver 17 stöds teckenuppsättningar och kodningar för SQLCHAR data bland annat:

Anmärkning

På grund av skillnader iconv mellan musl och glibc stöds många av dessa lokaler inte på Alpine Linux. För mer information, se Skillnader i funktionalitet jämfört med glibc.

Namn Description
UTF-8 Unicode
CP437 MS-DOS Latin-US
CP850 MS-DOS Latin 1
CP874 Latinsk/thailändsk
CP932 Japanska (Windows kodsida 932)
CP936 Förenklad kinesiska, GBK
CP949 Koreanska (Windows kodsida 949)
CP950 Traditionell kinesiska, Big5
CP1250 Centraleuropeisk
CP1251 Kyrilliska
CP1252 Västeuropeiska
CP1253 Grekiska
CP1254 Turkiska
CP1255 Hebreiska
CP1256 Arabiska
CP1257 Baltikum
CP1258 Vietnamesiska
ISO-8859-1 Latin-1
ISO-8859-2 Latin-2
ISO-8859-3 Latin-3
ISO-8859-4 Latin-4
ISO-8859-5 Latinsk/kyrillisk
ISO-8859-6 Latinsk/arabisk
ISO-8859-7 Latinsk/grekisk
ISO-8859-8 Hebreiska
ISO-8859-9 Turkiska
ISO-8859-13 Latin-7
ISO-8859-15 Latin-9

När du ansluter känner drivrutinen av den aktuella språkinställningen för processen som den läses in i. Om språkinställningen använder en av de listade kodningarna använder drivrutinen den kodningen för SQLCHAR data med smala tecken. Annars är det som standard UTF-8. Processer startar i C lokalen som standard, vilket gör att drivrutinen använder UTF-8 som standard. Om en applikation behöver någon av de listade kodningarna, anropa setlocale innan du ansluter. Specificera språkinställningen explicit, eller använd en tom sträng (till exempel setlocale(LC_ALL, "")) för att använda miljöns lokalinställningar.

I en typisk Linux- eller macOS-miljö där kodningen är UTF-8, kommer användare av ODBC Driver 17 som uppgraderar från 13 eller 13.1 inte att märka några skillnader. Applikationer som använder en listad icke-UTF-8-kodning genom setlocale måste använda den kodningen för data till och från drivrutinen istället för UTF-8.

Du måste använda UTF-16LE (little endian) för SQLWCHAR data.

När du binder indataparametrar med SQLBindParameter, om du anger en smal tecken SQL-typ såsom SQL_VARCHAR, konverterar drivrutinen den tillhandahållna datan från klientkodningen till serversidans kodning för den parametern. Kodningen beror på sorteringsordningen; det är inte alltid kodsida 1252. För utdataparametrar konverterar drivrutinen från kodningen som anges i sorteringsinformationen som är associerad med data till klientkodningen. Tecken i källkodningen som inte kan representeras i målkodningen omvandlas till ett frågetecken (?).

För att undvika denna dataförlust vid bindning av indataparametrar, ange en Unicode SQL-teckentyp såsom SQL_WVARCHAR. Drivrutinen konverterar klientkodningen till UTF-16, som kan representera alla Unicode-tecken. Målkolumnen eller parametern måste också vara en Unicode-typ (nchar, nvarchar eller ntext) eller en typ med en kollation eller kodning som kan representera all ursprungsdata. För utdataparametrar, ange en Unicode SQL-typ och antingen en Unicode C-typ (SQL_C_WCHAR), vilket gör att drivrutinen returnerar data som UTF-16, eller en smal C-typ med en klientkodning som kan representera källdatan. UTF-8 kan alltid representera denna data.

För mer information om kollationer och kodningar, se Collation och Unicode-stöd.

Det finns skillnader i konvertering mellan Windows och Linux- eller macOS-versionericonv:

  • För kodsida 1255 konverteras byte 0xCA till UTF-16-kodpunkt 0x05BA på Windows och till 0x00CA på macOS och Linux i versioner av libiconv tidigare än 1.15.
  • Linux-bibliotek iconv utan Big5/CP950:s 2003 års revidering (BIG5-2003) konverterar inte de tecken som lagts till i den revideringen korrekt.
  • För kodblad 932 (japanska, Shift-JIS) skiljer sig avkodningen av tecken som inte definieras i kodningsstandarden. Till exempel konverteras byte 0x80 till U+0080 på Windows och kan bli U+30FB på Linux och macOS, beroende på iconv version.

I ODBC Driver 13 och 13.1 leder uppdelning av UTF-8 multibyte-tecken eller UTF-16-surrogat över SQLPutData buffertar till datakorruption. Använd strömningsbuffertar som inte slutar med partiella teckenkodningar. Denna begränsning togs bort i ODBC Driver 17.

För vägledning om teckenkodning, konvertering, parameterbindning och buffertstorlek, se Kända problem.

OpenSSL

Från och med ODBC Driver 17.4 laddar drivrutinen OpenSSL dynamiskt, vilket gör att den kan köras på system som har version 1.0 eller 1.1 utan separata drivrutinsfiler. Från och med version 17.9 stöder drivrutinen OpenSSL 3.0 utöver tidigare versioner. När flera versioner av OpenSSL finns försöker drivrutinen ladda en stödd version från sina bibliotekssökvägar.

Drivrutinsversion OpenSSL-versioner som stöds
17,4 till 17,8 1,0, 1,1
17.9 och senare 17.x-versioner, samt alla Driver 18-versioner 1.0, 1.1, 3.0

OpenSSL 4 stöds inte. På macOS kan en Homebrew openssl länk som pekar på OpenSSL 4 förhindra att drivrutinen laddar OpenSSL även när OpenSSL 3 är installerat. Kontrollera bibliotekssökvägen samt de installerade versionerna.

Anmärkning

En potentiell konflikt kan uppstå om applikationen som använder drivrutinen, eller en av dess komponenter, länkar till eller dynamiskt laddar en annan version av OpenSSL. Om flera versioner av OpenSSL finns på systemet och applikationen använder det, se till att versionen som laddas av applikationen och drivrutinen överensstämmer. Felen kan orsaka minneskorruption och kanske inte visa sig på uppenbara eller konsekventa sätt.

Alpine Linux

Standardstackstorleken för nya trådar är i musl 128 KB om inte körfilen begär en större standard. En tråd kan överskrida denna gräns när den anropar drivrutinen. Länka en ODBC-applikation på Alpine Linux med -Wl,-z,stack-size=<size_in_bytes> för att begära en större standardtrådstack. Applikationer som skapar trådar med en explicit stackstorlek måste också välja en lämplig storlek för dessa trådar.

Huvudtrådens stack och standardstacken för nya trådar är inte samma inställning. På glibc system följer standarden för nya trådar normalt processens stackresursgräns, med en arkitekturspecifik reservplan när den gränsen är obegränsad. Anta inte ett fast standardvärde på 2 MB på Linux-system.

Ytterligare kommentarer

För att skapa en dedikerad administratörsanslutning (DAC) från en ODBC-applikation, ställ in ApplicationIntent=Server=tcp:<server>,<dac_port> i din anslutningssträng. Använd den upptäckta DAC-porten, inte instansens vanliga anslutningsport. Till exempel, om DAC-porten är 33000, sätt Server=tcp:<server>,33000. Dessa anslutningssträngfragment specificerar endast slutpunkten, inte autentisering. Konfigurera autentisering och validering av servercertifikat separat.

Inloggningskontot måste vara medlem i sysadmin serverrollen. Fjärråtkomst kräver att serverns alternativ för fjärradministratörsanslutningar är aktiverat. För åtkomstkrav, serverkonfiguration och kommandoradsadministrationsprocedurer, se Diagnostisk anslutning för databasadministratörer. För portupptäckt, se DAC-port.

unixODBC-drivrutinshanteraren hanterar satsattribut som skickas genom SQLSetConnectAttr på samma sätt som Windows Driver Manager. ODBC 2.x-instruktionsalternativ, såsom SQL_ATTR_QUERY_TIMEOUT och SQL_ATTR_MAX_ROWS, gäller för befintliga och nya instruktioner på anslutningen. ODBC 3.x-attribut endast för satser, såsom SQL_ATTR_ROW_ARRAY_SIZE och SQL_ATTR_PARAMSET_SIZE, returnerar SQLSTATE HY092. Attribut definierade på både anslutnings- och instruktionsnivå, såsom SQL_ATTR_METADATA_ID, kan sättas på båda nivåerna. Att sätta statement-only-attribut på anslutningsnivå är föråldrat i ODBC 3.x, så anropa SQLSetStmtAttr istället. För mer information, se SQLSetConnectAttr-funktionen.

I mycket flertrådade applikationer kan validering av unixODBC-handtaget bli en prestandaflaskhals. Att kompilera unixODBC med --enable-fastvalidate kan förbättra prestandan. Detta alternativ kan dock göra att applikationer som skickar ogiltiga handtag till ODBC-API:er kraschar istället för att returnera SQL_INVALID_HANDLE.

För plattformsinstallations- och konfigurationssteg, se: