Riktlinjer för programmering

Ladda ned ODBC-drivrutins

Programmeringsfunktionerna i Microsoft ODBC-drivrutinen för SQL Server på macOS och Linux baseras på ODBC i SQL Server Native Client (SQL Server Native Client (ODBC)). SQL Server Native Client baseras på ODBC i Windows Data Access Components (ODBC-programmerarens referens).

Ett ODBC-program kan använda flera aktiva resultatuppsättningar (MARS) och andra SQL Server-specifika funktioner genom att inkludera /usr/local/include/msodbcsql.h efter att ha inkluderat unixODBC-huvudena (sql.h, sqlext.h, sqltypes.h, och sqlucode.h). Använd sedan samma symboliska namn för SQL Server-specifika objekt som du skulle använda i dina Windows ODBC-program.

Tillgängliga funktioner

Följande avsnitt i dokumentationen för SQL Server Native Client för ODBC (SQL Server Native Client (ODBC)) är giltiga när du använder ODBC-drivrutinen på macOS och Linux:

• Kommunicera med SQL Server (ODBC)
• Stöd för anslutnings- och frågeutgångstid
• Cursors
• Förbättringar av datum/tid (ODBC)
• Köra frågor (ODBC)
• Hantera fel och meddelanden
• Kerberos-autentisering
• Stora CLR-User-Defined typer (ODBC)
• Utföra transaktioner (ODBC) (utom distribuerade transaktioner)
• Bearbetningsresultat (ODBC)
• Köra lagrade procedurer
• Stöd för glesa kolumner (ODBC)
• Använda kryptering utan verifiering
• Tabellvärdeparametrar
• UTF-8 och UTF-16 för kommando- och data-API
• Använda katalogfunktioner

Funktioner som inte stöds

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

• Anslutning till failoverkluster
• Transparent nätverks-IP-upplösning (före ODBC-drivrutin 17)
• Linux- och macOS ODBC-drivrutins-BID-spårning (före ODBC-drivrutin 17.3)

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

• Distribuerade transaktioner (SQL_ATTR_ENLIST_IN_DTC attribut stöds inte)
• Databas-spegeling
• FILESTREAM
• Profilering av ODBC-drivrutinsprestanda, som beskrivs i SQLSetConnectAttr, och följande 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 som SQL_C_INTERVAL_YEAR_TO_MONTH (dokumenterade i Identifierare för datatyp och beskrivningar)
• Värdet SQL_CUR_USE_ODBC för attributet SQL_ATTR_ODBC_CURSORS i funktionen SQLSetConnectAttr.

Stöd för teckenuppsättning

För ODBC-drivrutinen 13 och 13.1 måste SQLCHAR-data vara UTF-8. Inga andra kodningar stöds.

För ODBC Driver 17 stöds SQLCHAR-data i någon av följande teckenuppsättningar/kodningar:

Anmärkning

På grund iconv av skillnader i musl och glibc stöds inte många av dessa nationella inställningar på Alpine Linux.

Mer information finns i Funktionella skillnader från glibc

Namn	Description
UTF-8	Unicode
CP437	MS-DOS Latin-US
CP850	MS-DOS Latin 1
CP874	Latinsk/thailändsk
CP932	Japanska, Shift-JIS
CP936	Förenklad kinesiska, GBK
CP949	Koreanska, EUC-KR
CP950	Traditionell kinesiska, Big5
CP1251	Kyrilliska
CP1253	Grekiska
CP1256	Arabiska
CP1257	Baltikum
CP1258	Vietnamesiska
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	Latinsk/kyrillisk
ISO-8859-6	Latinsk/arabisk
ISO-8859-7	Latinsk/grekisk
ISO-8859-8 /CP1255	Hebreiska
ISO-8859-9 /CP1254	Turkiska
ISO-8859-13	Latin-7
ISO-8859-15	Latin-9

Vid anslutning identifierar drivrutinen det aktuella språket för den process som den läses in i. Om den använder någon av kodningarna ovan använder drivrutinen den kodningen för SQLCHAR-data (smaltecken). annars är utf-8 som standard. Eftersom alla processer startas i "C"-språkvarianten som standard (och gör att drivrutinen som standard är UTF-8), bör det använda funktionen setlocale för att ange nationella inställningar innan du ansluter, om ett program behöver använda någon av kodningarna ovan. antingen genom att uttryckligen ange nationella inställningar eller genom att använda en tom sträng för att till exempel setlocale(LC_ALL, "") använda nationella inställningar för miljön.

I en typisk Linux- eller macOS-miljö där kodningen är UTF-8 ser användare av ODBC Driver 17 som uppgraderar från 13 eller 13.1 därför inga skillnader. Program som använder en icke-UTF-8-kodning i listan ovan måste setlocale() dock använda den kodningen för data till/från drivrutinen i stället för UTF-8.

SQLWCHAR-data måste vara UTF-16LE (Little Endian).

När du binder indataparametrar med SQLBindParameter konverterar drivrutinen angivna data från klientkodningen till standardkodningen (vanligtvis kodsida 1252) om du anger en SQL Server-kodning med ett smalt tecken, till exempel SQL_VARCHAR. För utdataparametrar konverterar drivrutinen från kodningen som anges i sorteringsinformationen som är associerad med data till klientkodningen. Dataförlust är dock möjligt --- tecken i källkodningen som inte kan representeras i målkodningen konverteras till ett frågetecken (?).

Om du vill undvika den här dataförlusten vid bindning av indataparametrar anger du en Unicode SQL-teckentyp, till exempel SQL_NVARCHAR. I det här fallet konverterar drivrutinen från klientkodningen till UTF-16, vilket kan representera alla Unicode-tecken. Dessutom måste målkolumnen eller parametern på servern också vara en Unicode-typ (nchar, nvarchar, ntext) eller en med sortering/kodning, som kan representera alla tecken i de ursprungliga källdata. För att undvika dataförlust med utdataparametrar anger du 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 och ser till att klientkodningen kan representera alla tecken i källdata (den här representationen är alltid möjlig med UTF-8.)

Mer information om sortering och kodningar finns i Sortering och Unicode-support.

Det finns vissa skillnader i kodningskonvertering mellan Windows och flera versioner av iconv-biblioteket i Linux och macOS. Textdata på kodsida 1255 (hebreiska) har en kodpunkt (0xCA) som fungerar annorlunda vid konvertering till Unicode. I Windows konverteras det här tecknet till UTF-16-kodpunkten för 0x05BA. I macOS och Linux med tidigare libiconv-versioner än 1.15 konverteras det till 0x00CA. I Linux med iconv-bibliotek som inte stöder 2003 års revision av Big5/CP950 (med namnet BIG5-2003), konverteras inte tecken som lagts till med den revisionen korrekt. I kodsida 932 (japanska, Shift-JIS) skiljer sig även resultatet från avkodningen av tecken som inte ursprungligen definierades i kodningsstandarden. Byte 0x80 konverteras till U+0080 i Windows men kan bli U+30FB i Linux och macOS, beroende på iconv-version.

I ODBC-drivrutinen 13 och 13.1, när UTF-8 flerbytestecken eller UTF-16-surrogater delas mellan SQLPutData-buffertar, resulterar det i datakorruption. Använd buffertar för strömmande SQLPutData som inte slutar med partiella teckenkodningar. Den här begränsningen har tagits bort med ODBC Driver 17.

OpenSSL

Från och med version 17.4 läser drivrutinen in OpenSSL dynamiskt, vilket gör att den kan köras på system som har antingen version 1.0 eller 1.1 utan behov av separata drivrutinsfiler. Från och med version 17.9 stöder drivrutinen OpenSSL 3.0 utöver tidigare versioner. När det finns flera versioner av OpenSSL försöker drivrutinen läsa in den senaste.

Drivrutinsversion	OpenSSL-versioner som stöds
17.4+	1.0, 1.1
17.9, 18.0+	1.0, 1.1, 3.0

Anmärkning

En potentiell konflikt kan uppstå om programmet som använder drivrutinen (eller någon av dess komponenter) är länkat till eller dynamiskt läser in en annan version av OpenSSL. Om flera versioner av OpenSSL finns i systemet och programmet använder det rekommenderar vi starkt att du är extra försiktig med att se till att den version som läses in av programmet och drivrutinen inte matchar fel, eftersom felen kan skada minnet och därför inte nödvändigtvis visas på uppenbara eller konsekventa sätt.

Alpine Linux

När detta skrivs är standardstackens storlek i MUSL 128K, vilket räcker för grundläggande ODBC-drivrutinsfunktioner, men beroende på vad programmet gör är det inte svårt att överskrida den här gränsen, särskilt när du anropar drivrutinen från flera trådar. Vi rekommenderar att ett ODBC-program på Alpine Linux kompileras med -Wl,-z,stack-size=<VALUE IN BYTES> för att öka stackstorleken. Som referens är standardstackens storlek på de flesta GLIBC-system 2 MB.

Ytterligare anteckningar

• Du kan skapa en dedikerad administratörsanslutning (DAC) med hjälp av SQL Server-autentisering och värd,port. En medlem i Sysadmin-rollen måste först identifiera DAC-porten. Se diagnostikanslutning för databasadministratörer för att upptäcka hur. Om DAC-porten till exempel var 33000 kan du ansluta till den med sqlcmd följande:

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

  Anmärkning

  DAC-anslutningar måste använda SQL Server-autentisering.

• UnixODBC-drivrutinshanteraren returnerar "ogiltig attribut/alternatividentifierare" för alla instruktionsattribut när de skickas via SQLSetConnectAttr. I Windows, när SQLSetConnectAttr tar emot ett anslutningsattributvärde, leder det till att drivrutinen anger det värdet på alla aktiva uttalanden, som är underordnade anslutningshandtaget.

• När du använder drivrutinen med mycket flertrådade program kan unixODBC:s hanteringsverifiering bli en flaskhals för prestanda. I sådana scenarier kan högre prestanda erhållas genom kompilering av unixODBC med alternativet --enable-fastvalidate . Tänk dock på att det här alternativet kan leda till att program som skickar ogiltiga referenser till ODBC-API:er kraschar istället för att returnera SQL_INVALID_HANDLE fel.

Se även

Vanliga frågor och svar
Kända problem i den här versionen av drivrutinen
Viktig information