Sdílet prostřednictvím


Pokyny pro programování

Stáhnout ovladač ODBC

Programovací funkce ovladače Microsoft ODBC pro SQL Server v systému macOS a Linux jsou založené na rozhraní ODBC v sql Server Native Client (SQL Server Native Client (ODBC)). Nativní klient SQL Serveru je založený na rozhraní ODBC v komponentách přístupu k datům systému Windows (referenční dokumentace programátora ODBC).

Aplikace ODBC může používat více aktivních sad výsledků (MARS) a dalších funkcí specifických pro SQL Server, a to zahrnutím /usr/local/include/msodbcsql.h hlaviček unixODBC (sql.h, sqlext.h, sqltypes.ha sqlucode.h). Potom použijte stejné symbolické názvy položek specifických pro SQL Server, které byste použili v aplikacích ODBC systému Windows.

Dostupné funkce

Následující části z dokumentace k nativnímu klientovi SQL Serveru pro rozhraní ODBC (SQL Server Native Client (ODBC)) jsou platné při použití ovladače ODBC v systému macOS a Linux:

Nepodporované funkce

Následující funkce nebyly ověřeny tak, aby správně fungovaly v ovladači ODBC v systémech macOS a Linux:

V ovladači ODBC v systémech macOS a Linux nejsou k dispozici následující funkce:

  • Distribuované transakce (atribut SQL_ATTR_ENLIST_IN_DTC se nepodporuje)
  • Zrcadlení databáze
  • FILESTREAM
  • Profilace výkonu ovladače ODBC, probírané v SQLSetConnectAttr a následující atributy připojení související s výkonem:
    • 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 (před verzí 17.2)
  • Typy intervalů jazyka C, jako jsou SQL_C_INTERVAL_YEAR_TO_MONTH (zdokumentované v identifikátorech a popisovačích datových typů)
  • Hodnota SQL_CUR_USE_ODBC atributu SQL_ATTR_ODBC_CURSORS funkce SQLSetConnectAttr.

Podpora znakové sady

Pro ovladač ODBC 13 a 13.1 musí být data SQLCHAR UTF-8. Nejsou podporována žádná jiná kódování.

U ovladače ODBC 17 se podporují data SQLCHAR v jedné z následujících znakových sad a kódování:

Poznámka:

Vzhledem k rozdílům iconv v musl a glibc nejsou mnohé z těchto místních prostředí v Alpine Linuxu podporovány.

Další informace naleznete v tématu Funkční rozdíly od glibc

Název Description
UTF-8 Unicode
CP437 MS-DOS usa – latinka
CP850 MS-DOS latinka 1
CP874 Latinka/thajština
CP932 Japonština, Shift-JIS
CP936 Zjednodušená čínština, GBK
CP949 Korejština, EUC-KR
CP950 Tradiční čínština, Big5
CP1251 Cyrilice
CP1253 Řečtina
CP1256 Arabština
CP1257 Balt
CP1258 Vietnamština
ISO-8859-1 / CP1252 Latinka-1
ISO-8859-2 / CP1250 Latinka-2
ISO-8859-3 Latinka-3
ISO-8859-4 Latin-4
ISO-8859-5 Latinka/cyrilice
ISO-8859-6 Latinka/arabština
ISO-8859-7 Latinka/řečtina
ISO-8859-8 / CP1255 Hebrejština
ISO-8859-9 / CP1254 Turečtina
ISO-8859-13 Latinka-7
ISO-8859-15 Latin-9

Při připojení ovladač zjistí aktuální národní prostředí procesu, do něhož je načten. Pokud používá některý z výše uvedených kódování, ovladač použije toto kódování pro data SQLCHAR (úzký znak). jinak se ve výchozím nastavení nastaví UTF-8. Vzhledem k tomu, že všechny procesy se ve výchozím nastavení spouští v národním prostředí "C" (a způsobují, že ovladač má výchozí hodnotu UTF-8), pokud aplikace potřebuje použít některý z výše uvedených kódování, měla by použít funkci setlocale k nastavení národního prostředí odpovídajícím způsobem před připojením; buď explicitním zadáním národního prostředí, nebo použitím prázdného řetězce, například setlocale(LC_ALL, "") k použití nastavení národního prostředí.

Proto v typickém prostředí s Linuxem nebo macOS, kde kódování je UTF-8, uživatelé ovladače ODBC 17, kteří upgradují z verze 13 nebo 13.1, neuvidí žádné rozdíly. Aplikace, které v seznamu výše setlocale() používají kódování jiného typu než UTF-8, však musí použít toto kódování pro data do/z ovladače místo UTF-8.

Data SQLWCHAR musí být UTF-16LE (Little Endian).

Při vytváření vazby vstupních parametrů pomocí SQLBindParameter, pokud je zadán úzký znak typu SQL, jako je například SQL_VARCHAR, ovladač převede zadaná data z kódování klienta na výchozí (obvykle kódovou stránku 1252) kódování SQL Serveru. U výstupních parametrů ovladač převede kódování zadané v informacích kolace přidružených k datům na kódování klienta. Ztráta dat je však možná --- znaky ve zdrojovém kódování, které není v cílovém kódování reprezentovatelné, se převedou na otazník (?).

Pokud se chcete této ztrátě dat vyhnout při vazbě vstupních parametrů, zadejte typ znaku SQL unicode, například SQL_NVARCHAR. V tomto případě ovladač převede kódování klienta na UTF-16, který může představovat všechny znaky Unicode. Cílový sloupec nebo parametr na serveru navíc musí být buď typem Unicode (nchar, nvarchar, ntext), nebo jedním s kolací nebo kódováním, které může představovat všechny znaky původních zdrojových dat. Pokud se chcete vyhnout ztrátě dat pomocí výstupních parametrů, zadejte typ UNICODE SQL a buď typ Unicode C (SQL_C_WCHAR), který ovladač vrátí data jako UTF-16, nebo úzký typ C, a ujistěte se, že kódování klienta může představovat všechny znaky zdrojových dat (toto vyjádření je vždy možné pomocí UTF-8.)

Další informace o kolacích a kódováních najdete v tématu Podpora kolace a kódování Unicode.

Mezi Windows a několika verzemi knihovny iconv v Linuxu a macOS existuje několik rozdílů v převodu kódování. Textová data na znakové stránce 1255 (hebrejština) mají jeden bod kódu (0xCA), který se při převodu na Unicode chová jinak. Ve Windows se tento znak převede na bod kódu UTF-16 0x05BA. V systému macOS a Linux s verzemi libiconv staršími než 1.15 se převede na 0x00CA. V Linuxu s knihovnami iconv, které nepodporují revizi Big5/CP950 (pojmenované BIG5-2003) 2003, se znaky přidané s danou revizí nepřevedou správně. Na znakové stránce 932 (japonština, Shift-JIS), výsledek dekódování znaků, které nejsou původně definovány v kódovací normě, se také liší. Například bajt 0x80 je převeden na U+0080 ve Windows, ale v závislosti na verzi iconv se může stát U+30FB v Linuxu a macOS.

V ovladači ODBC 13 a 13.1, když jsou vícebajtové znaky UTF-8 nebo náhradní znaky UTF-16 rozděleny mezi vyrovnávací paměti SQLPutData, dojde k poškození dat. Pro streamování SQLPutData použijte vyrovnávací paměti, které nekončí částečným kódováním znaků. Toto omezení bylo odebráno ovladačem ODBC 17.

OpenSSL

Počínaje verzí 17.4 ovladač načte OpenSSL dynamicky, což umožňuje spuštění v systémech, které mají buď verzi 1.0, nebo 1.1 bez nutnosti samostatných souborů ovladačů. Od verze 17.9 ovladač kromě předchozích verzí podporuje OpenSSL 3.0. Pokud je k dispozici více verzí OpenSSL, ovladač se pokusí načíst nejnovější verzi.

Verze ovladače Podporované verze OpenSSL
17.4+ 1.0, 1.1
17.9, 18.0+ 1.0, 1.1, 3.0

Poznámka:

K potenciálnímu konfliktu může dojít v případě, že aplikace, která používá ovladač (nebo jednu z jejích komponent), je propojená nebo dynamicky načte jinou verzi OpenSSL. Pokud je v systému přítomno několik verzí OpenSSL a aplikace ho používá, důrazně doporučujeme, abyste byli opatrní, aby se zajistilo, že verze načtená aplikací a ovladač se neshoduje, protože chyby by mohly poškodit paměť, a proto se nemusí nutně projevit jasnými nebo konzistentními způsoby.

Alpine Linux

V době psaní tohoto zápisu výchozí velikosti zásobníku v MUSL je 128 tisíc, což je dostatečné pro základní funkce ovladače ODBC, ale v závislosti na tom, co aplikace dělá, není obtížné tento limit překročit, zejména při volání ovladače z více vláken. Doporučuje se, aby se aplikace ODBC v Alpine Linuxu kompilovala -Wl,-z,stack-size=<VALUE IN BYTES> s cílem zvětšit velikost zásobníku. Pro referenci je výchozí velikost zásobníku ve většině systémů GLIBC 2 MB.

Další poznámky

  • Můžete vytvořit vyhrazené připojení správce (DAC) pomocí ověřování SQL Serveru a hostu, portu. Nejprve musí zjistit port DAC člen role správce systému. Postup najdete v tématu Diagnostické připojení pro správce databází . Pokud byl například port DAC 33000, můžete se k němu sqlcmd připojit následujícím způsobem:

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

    Poznámka:

    Připojení DAC musí používat ověřování na SQL Serveru.

  • Správce ovladačů UnixODBC vrátí "neplatný identifikátor atributu/možnosti" pro všechny atributy příkazů, když jsou předány prostřednictvím SQLSetConnectAttr. Když SQLSetConnectAttr ve Windows obdrží hodnotu atributu příkazu, způsobí, že ovladač nastaví danou hodnotu u všech aktivních příkazů, které jsou podřízené popisovači připojení.

  • Při použití ovladače s vysoce vícevláknovými aplikacemi se ověření popisovače unixODBC může stát kritickým bodem výkonu. V takových scénářích může být vyšší výkon získán kompilováním unixODBC s --enable-fastvalidate možností. Mějte však na pozoru, že tato možnost může způsobit, že aplikace, které předávají neplatné popisovače ODBC API, mohou místo vrácení chyb způsobit pád aplikace.

Viz také

Nejčastější dotazy
Známé problémy v této verzi ovladače
Poznámky k vydání