Share via

Programmeerrichtlijnen

ODBC-stuurprogramma downloaden

De programmeerfuncties van het Microsoft ODBC-stuurprogramma voor SQL Server in macOS en Linux zijn gebaseerd op ODBC in SQL Server Native Client (SQL Server Native Client (ODBC)). SQL Server Native Client is gebaseerd op ODBC in Windows Data Access Components (ODBC Programmer's Reference).

Een ODBC-toepassing kan MARS (Multiple Active Result Sets) en andere SQL Server-specifieke functies gebruiken door na de unixODBC-headers (sql.h, sqlext.h, sqltypes.h, en sqlucode.h) op te geven. Gebruik vervolgens dezelfde symbolische namen voor SQL Server-specifieke items die u zou gebruiken in uw Windows ODBC-toepassingen.

Beschikbare functies

De volgende secties in de documentatie van sql Server Native Client voor ODBC (SQL Server Native Client (ODBC)) zijn geldig wanneer u het ODBC-stuurprogramma op macOS en Linux gebruikt:

Niet-ondersteunde functies

De volgende functies zijn niet gecontroleerd om correct te werken in het ODBC-stuurprogramma op macOS en Linux:

De volgende functies zijn niet beschikbaar in het ODBC-stuurprogramma op macOS en Linux:

  • Gedistribueerde transacties (SQL_ATTR_ENLIST_IN_DTC kenmerk wordt niet ondersteund)
  • Databasespiegeling
  • FILESTREAM
  • De prestaties van ODBC-stuurprogramma's profileren, besproken in SQLSetConnectAttr en de volgende prestatiegerelateerde verbindingskenmerken:
    • 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 (vóór versie 17.2)
  • C-intervaltypen zoals SQL_C_INTERVAL_YEAR_TO_MONTH (gedocumenteerd in gegevenstype-id's en descriptors)
  • De SQL_CUR_USE_ODBC waarde van het kenmerk SQL_ATTR_ODBC_CURSORS van de functie SQLSetConnectAttr.

Ondersteuning voor tekenset

Voor ODBC-stuurprogramma 13 en 13.1 moeten SQLCHAR-gegevens UTF-8 zijn. Er worden geen andere coderingen ondersteund.

Voor ODBC-stuurprogramma 17 worden SQLCHAR-gegevens in een van de volgende tekensets/coderingen ondersteund:

Opmerking

Vanwege verschillen in musl en glibc worden veel van deze locaties niet ondersteund in Alpine Linux.

Zie Functionele verschillen van glibc voor meer informatie

Naam Description
UTF-8 Unicode
CP437 MS-DOS Latijns-VS
CP850 MS-DOS Latijns 1
CP874 Latijns/Thais
CP932 Japans, Shift-JIS
CP936 Vereenvoudigd Chinees, GBK
CP949 Koreaans, EUC-KR
CP950 Traditioneel Chinees, Big5
CP1251 Cyrillisch
CP1253 Grieks
CP1256 Arabisch
CP1257 Baltische
CP1258 Vietnamees
ISO-8859-1 / CP1252 Latijns-1
ISO-8859-2 / CP1250 Latijns-2
ISO-8859-3 Latijns-3
ISO-8859-4 Latijns-4
ISO-8859-5 Latijns/Cyrillisch
ISO-8859-6 Latijns/Arabisch
ISO-8859-7 Latijns/Grieks
ISO-8859-8 / CP1255 Hebreeuws
ISO-8859-9 / CP1254 Turkse taal
ISO-8859-13 Latijns-7
ISO-8859-15 Latijns-9

Bij de verbinding detecteert het stuurprogramma de huidige landinstelling van het proces waarin het is geladen. Als er een van de bovenstaande coderingen wordt gebruikt, gebruikt het stuurprogramma die codering voor SQLCHAR-gegevens (narrow-character). anders wordt standaard UTF-8 gebruikt. Aangezien alle processen standaard worden gestart in de landinstelling C (en ervoor zorgen dat het stuurprogramma standaard UTF-8 is), moet een toepassing, als een toepassing een van de bovenstaande coderingen moet gebruiken, de setlocale-functie gebruiken om de landinstelling op de juiste manier in te stellen voordat er verbinding wordt gemaakt; door de landinstelling expliciet op te geven of door een lege tekenreeks te gebruiken, bijvoorbeeld setlocale(LC_ALL, "") om de landinstellingen van de omgeving te gebruiken.

Daarom, in een typische Linux- of macOS-omgeving waarin de codering UTF-8 is, zien gebruikers van ODBC-stuurprogramma 17 upgraden van 13 of 13.1 geen verschillen. Toepassingen die echter een niet-UTF-8-codering gebruiken in de bovenstaande lijst, moeten die setlocale() codering gebruiken voor gegevens naar/van het stuurprogramma in plaats van UTF-8.

SQLWCHAR-gegevens moeten UTF-16LE (Little Endian) zijn.

Wanneer u invoerparameters bindt met SQLBindParameter, en een SQL-type voor smalle tekens zoals SQL_VARCHAR is opgegeven, converteert het stuurprogramma de gegevens van de clientcodering naar de standaard SQL Server-codering (meestal codepagina 1252). Voor uitvoerparameters converteert het stuurprogramma van de codering die is opgegeven in de sorteringsgegevens die zijn gekoppeld aan de gegevens naar de clientcodering. Gegevensverlies is echter mogelijk --- tekens die in de broncodering niet kunnen worden weergegeven in de doelcodering, worden omgezet in een vraagteken ('?').

Als u dit gegevensverlies wilt voorkomen bij bindingsinvoerparameters, geeft u een Unicode SQL-tekentype op, zoals SQL_NVARCHAR. In dit geval converteert het stuurprogramma van de clientcodering naar UTF-16, die alle Unicode-tekens kan vertegenwoordigen. Bovendien moet de doelkolom of parameter op de server ook een Unicode-type (nchar, nvarchar, ntext) of een met een sortering/codering zijn, die alle tekens van de oorspronkelijke brongegevens kan vertegenwoordigen. Als u gegevensverlies met uitvoerparameters wilt voorkomen, geeft u een Unicode SQL-type op en een Unicode C-type (SQL_C_WCHAR), waardoor het stuurprogramma gegevens retourneert als UTF-16 of een smal C-type en ervoor zorgt dat de clientcodering alle tekens van de brongegevens kan vertegenwoordigen (deze weergave is altijd mogelijk met UTF-8.)

Zie Sortering en Unicode-ondersteuning voor meer informatie over sorteringen en coderingen.

Er zijn enkele coderingsconversieverschillen tussen Windows en verschillende versies van de iconv-bibliotheek in Linux en macOS. Tekstgegevens in codepagina 1255 (Hebreeuws) hebben één codepunt (0xCA) dat zich anders gedraagt bij conversie naar Unicode. In Windows wordt dit teken geconverteerd naar het UTF-16-codepunt van 0x05BA. In macOS en Linux met libiconv-versies ouder dan 1.15, wordt deze geconverteerd naar 0x00CA. In Linux met iconv-bibliotheken die geen ondersteuning bieden voor de 2003-revisie van Big5/CP950 (benoemd BIG5-2003), worden tekens die met die revisie zijn toegevoegd, niet correct geconverteerd. In codepagina 932 (Japans, Shift-JIS), verschilt het resultaat van het decoderen van tekens die niet oorspronkelijk in de coderingsstandaard zijn gedefinieerd. De byte-0x80 wordt bijvoorbeeld geconverteerd naar U+0080 in Windows, maar kan U+30FB worden op Linux en macOS, afhankelijk van de iconv-versie.

In ODBC-stuurprogramma 13 en 13.1, waarbij UTF-8 multibyte tekens of UTF-16 surrogaatparen worden opgesplitst in SQLPutData-buffers, leidt dit tot corruptie van gegevens. Gebruik buffers voor het streamen van SQLPutData die niet eindigen op gedeeltelijke tekencoderingen. Deze beperking is verwijderd met ODBC-stuurprogramma 17.

OpenSSL

Vanaf versie 17.4 laadt het stuurprogramma OpenSSL dynamisch, zodat het kan worden uitgevoerd op systemen met versie 1.0 of 1.1 zonder dat er afzonderlijke stuurprogrammabestanden nodig zijn. Vanaf versie 17.9 ondersteunt het stuurprogramma OpenSSL 3.0 naast de vorige versies. Wanneer er meerdere versies van OpenSSL aanwezig zijn, probeert het stuurprogramma de nieuwste versie te laden.

Versie van het stuurprogramma Ondersteunde OpenSSL-versies
17.4+ 1.0, 1.1
17.9, 18.0+ 1.0, 1.1, 3.0

Opmerking

Er kan een mogelijk conflict optreden als de toepassing die gebruikmaakt van het stuurprogramma (of een van de onderdelen) is gekoppeld aan of dynamisch een andere versie van OpenSSL laadt. Als er verschillende versies van OpenSSL aanwezig zijn op het systeem en de toepassing het gebruikt, is het ten zeerste aanbevolen extra voorzichtig te zijn om ervoor te zorgen dat de door de toepassing geladen versie en het stuurprogramma elkaar niet tegenspreken, omdat fouten het geheugen kunnen beschadigen en zich daardoor niet op duidelijke of consistente manieren hoeven te manifesteren.

Alpine Linux

Op het moment van schrijven is de standaardstackgrootte in MUSL 128K, wat voldoende is voor eenvoudige ODBC-stuurprogrammafunctionaliteit, maar afhankelijk van wat de toepassing doet, is het niet moeilijk om deze limiet te overschrijden, vooral bij het aanroepen van het stuurprogramma vanuit meerdere threads. Het wordt aanbevolen om een ODBC-toepassing op Alpine Linux te compileren met -Wl,-z,stack-size=<VALUE IN BYTES> om de stackgrootte te vergroten. Ter referentie is de standaardstackgrootte op de meeste GLIBC-systemen 2 MB.

Aanvullende notities

  • U kunt een toegewezen beheerdersverbinding (DAC) maken met behulp van SQL Server-verificatie en -host, poort. Een lid van de rol Sysadmin moet eerst de DAC-poort detecteren. Zie De diagnostische verbinding voor databasebeheerders om te ontdekken hoe u dit kunt doen. Als de DAC-poort bijvoorbeeld 33000 is, kunt u er als volgt verbinding mee maken sqlcmd :

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

    Opmerking

    DAC-verbindingen moeten GEBRUIKMAKEN van SQL Server-verificatie.

  • De UnixODBC-stuurprogrammabeheer retourneert 'ongeldig kenmerk/optie-id' voor alle instructiekenmerken wanneer ze worden doorgegeven via SQLSetConnectAttr. In Windows, wanneer SQLSetConnectAttr een waarde voor het instructiekenmerk ontvangt, zorgt dit ervoor dat het stuurprogramma die waarde instelt voor alle actieve instructies, die onderliggende elementen van de verbindingsgreep zijn.

  • Wanneer u het stuurprogramma met zeer multithreaded toepassingen gebruikt, kan de validatie van de ingang van UNIXODBC een knelpunt voor prestaties worden. In dergelijke scenario's kunnen hogere prestaties worden verkregen door unixODBC te compileren met de --enable-fastvalidate optie. Let er echter op dat deze optie ertoe kan leiden dat toepassingen die ongeldige ingangen doorgeven aan ODBC-API's, vastlopen in plaats van fouten te retourneren SQL_INVALID_HANDLE .

Zie ook

Veelgestelde vragen
bekende problemen in deze versie van het stuurprogramma
Opmerkingen bij de release

  • Last updated on