Pedoman Pemrograman

Artikel
06/02/2023

Fitur pemrograman Driver Microsoft ODBC untuk SQL Server di macOS dan Linux didasarkan pada ODBC di SQL Server Native Client (SQL Server Native Client (ODBC)). SQL Server Native Client didasarkan pada ODBC di Komponen Akses Data Windows (Referensi Pemrogram ODBC).

Aplikasi ODBC dapat menggunakan Beberapa Set Hasil Aktif (MARS) dan fitur spesifik SQL Server lainnya dengan menyertakan /usr/local/include/msodbcsql.h setelah menyertakan header unixODBC (sql.h, sqlext.h, sqltypes.h, dan sqlucode.h). Kemudian gunakan nama simbolis yang sama untuk item khusus SQL Server yang akan Anda gunakan di aplikasi Windows ODBC Anda.

Fitur yang Tersedia

Bagian berikut dari dokumentasi SQL Server Native Client untuk ODBC (SQL Server Native Client (ODBC)) valid saat menggunakan driver ODBC di macOS dan Linux:

Fitur yang Tidak Didukung

Fitur berikut belum diverifikasi untuk bekerja dengan benar di driver ODBC di macOS dan Linux:

Koneksi Kluster Failover
Resolusi IP Jaringan Transparan (sebelum Driver ODBC 17)
Pelacakan BID Driver ODBC Linux dan macOS (sebelum Driver ODBC 17.3)

Fitur berikut tidak tersedia di driver ODBC di macOS dan Linux:

Transaksi Terdistribusi (atribut SQL_ATTR_ENLIST_IN_DTC tidak didukung)
Pencerminan Database
FILESTREAM
Memprofilkan performa driver ODBC, dibahas di SQLSetConnectAttr, dan atribut koneksi terkait performa berikut:
- 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 (sebelum versi 17.2)
Jenis interval C seperti SQL_C_INTERVAL_YEAR_TO_MONTH (didokumenkan dalam Pengidentifikasi dan Deskriptor Tipe Data)
Nilai SQL_CUR_USE_ODBC atribut SQL_ATTR_ODBC_CURSORS dari fungsi SQLSetConnectAttr.

Dukungan Set Karakter

Untuk ODBC Driver 13 dan 13.1, data SQLCHAR harus UTF-8. Tidak ada pengodean lain yang didukung.

Untuk ODBC Driver 17, data SQLCHAR dalam salah satu set/pengodean karakter berikut didukung:

Catatan

iconv Karena perbedaan dan musl glibc banyak lokal ini tidak didukung di Alpine Linux.

Untuk informasi selengkapnya, lihat Perbedaan fungsi dari glibc

Nama	Deskripsi
UTF-8	Unicode
CP437	MS-DOS Latin US
CP850	MS-DOS Latin 1
CP874	Latin/Thai
CP932	Jepang, Shift-JIS
CP936	Tionghoa Sederhana, GBK
CP949	Korea, EUC-KR
CP950	Tionghoa Tradisional, Big5
CP1251	Sirilik
CP1253	Yunani
CP1256	Arab
CP1257	Baltik
CP1258	Vietnam
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	Latin/Sirilik
ISO-8859-6	Latin/Arab
ISO-8859-7	Bahasa Latin/Yunani
ISO-8859-8 / CP1255	Ibrani
ISO-8859-9 / CP1254	Turki
ISO-8859-13	Latin-7
ISO-8859-15	Latin-9

Setelah koneksi, driver mendeteksi lokal saat ini dari proses yang dimuatnya. Jika menggunakan salah satu pengodean di atas, driver menggunakan pengodean tersebut untuk data SQLCHAR (karakter sempit) ; jika tidak, defaultnya ke UTF-8. Karena semua proses dimulai di lokal "C" secara default (dan menyebabkan driver default ke UTF-8), jika aplikasi perlu menggunakan salah satu pengodean di atas, aplikasi harus menggunakan fungsi setlocale untuk mengatur lokal dengan tepat sebelum menyambungkan; baik dengan menentukan lokal secara eksplisit, atau menggunakan string kosong misalnya setlocale(LC_ALL, "") untuk menggunakan pengaturan lokal lingkungan.

Oleh karena itu, di lingkungan Linux atau macOS yang khas di mana pengodeannya adalah UTF-8, pengguna ODBC Driver 17 yang meningkatkan dari 13 atau 13.1 tidak akan mengamati perbedaan apa pun. Namun, aplikasi yang menggunakan pengodean non-UTF-8 dalam daftar di atas melalui setlocale() perlu menggunakan pengodean tersebut untuk data ke/dari driver alih-alih UTF-8.

Data SQLWCHAR harus UTF-16LE (Little Endian).

Saat mengikat parameter input dengan SQLBindParameter, jika jenis SQL karakter sempit seperti SQL_VARCHAR ditentukan, driver mengonversi data yang disediakan dari pengodean klien ke pengodean SQL Server default (biasanya codepage 1252). Untuk parameter output, driver mengonversi dari pengodean yang ditentukan dalam informasi kolase yang terkait dengan data ke pengodean klien. Namun, kehilangan data dimungkinkan --- karakter dalam pengodean sumber yang tidak dapat diwakili dalam pengodean target akan dikonversi ke tanda tanya ('?').

Untuk menghindari kehilangan data ini saat mengikat parameter input, tentukan jenis karakter Unicode SQL seperti SQL_NVARCHAR. Dalam hal ini, driver mengonversi dari pengodean klien ke UTF-16, yang dapat mewakili semua karakter Unicode. Selain itu, kolom target atau parameter di server juga harus berupa jenis Unicode (nchar, nvarchar, ntext) atau satu dengan kolase/pengodean, yang dapat mewakili semua karakter data sumber asli. Untuk menghindari kehilangan data dengan parameter output, tentukan jenis Unicode SQL, dan jenis Unicode C (SQL_C_WCHAR), menyebabkan driver mengembalikan data sebagai UTF-16, atau jenis C sempit, dan memastikan bahwa pengodean klien dapat mewakili semua karakter data sumber (representasi ini selalu dimungkinkan dengan UTF-8.)

Untuk informasi selengkapnya tentang kolade dan pengodean, lihat Kolate dan Dukungan Unicode.

Ada beberapa perbedaan konversi pengodean antara Windows dan beberapa versi pustaka iconv di Linux dan macOS. Data teks dalam codepage 1255 (Ibrani) memiliki satu titik kode (0xCA) yang berakibat berbeda setelah konversi ke Unicode. Pada Windows, karakter ini dikonversi ke titik kode UTF-16 0x05BA. Di macOS dan Linux dengan versi libiconv yang lebih lama dari 1.15, versi tersebut dikonversi ke 0x00CA. Di Linux dengan pustaka iconv yang tidak mendukung revisi 2003 Big5/CP950 (bernama BIG5-2003), karakter yang ditambahkan dengan revisi tersebut tidak akan dikonversi dengan benar. Dalam codepage 932 (Jepang, Shift-JIS), hasil decoding karakter yang awalnya tidak didefinisikan dalam standar pengodean juga berbeda. Misalnya, byte 0x80 dikonversi ke U+0080 di Windows tetapi mungkin menjadi U+30FB di Linux dan macOS, tergantung pada versi iconv.

Dalam ODBC Driver 13 dan 13.1, ketika karakter multibyte UTF-8 atau pengganti UTF-16 dibagi di seluruh buffer SQLPutData, itu mengakibatkan kerusakan data. Gunakan buffer untuk streaming SQLPutData yang tidak berakhiran pengodean karakter parsial. Batasan ini telah dihapus dengan Odbc Driver 17.

OpenSSL

Dimulai dengan versi 17.4, driver memuat OpenSSL secara dinamis, yang memungkinkannya untuk berjalan pada sistem yang memiliki versi 1.0 atau 1.1 tanpa perlu file driver terpisah. Dimulai dengan versi 17.9, driver mendukung OpenSSL 3.0 selain versi sebelumnya. Ketika beberapa versi OpenSSL ada, driver akan mencoba memuat versi terbaru.

Versi driver	Versi OpenSSL yang didukung
17.4+	1.0, 1.1
17.9, 18.0+	1.0, 1.1, 3.0

Catatan

Potensi konflik dapat terjadi jika aplikasi yang menggunakan driver (atau salah satu komponennya) ditautkan dengan atau secara dinamis memuat versi OpenSSL yang berbeda. Jika beberapa versi OpenSSL ada pada sistem dan aplikasi menggunakannya, sangat disarankan agar seseorang berhati-hati dalam memastikan bahwa versi yang dimuat oleh aplikasi dan driver tidak tidak cocok, karena kesalahan dapat merusak memori dan dengan demikian tidak akan selalu bermanifestasi dengan cara yang jelas atau konsisten.

Alpine Linux

Pada saat penulisan ini, ukuran tumpukan default di MUSL adalah 128K, yang cukup untuk fungsionalitas driver ODBC dasar, namun tergantung pada apa yang dilakukan aplikasi tidak sulit untuk melebihi batas ini, terutama ketika memanggil driver dari beberapa utas. Disarankan agar aplikasi ODBC di Alpine Linux dikompilasi dengan -Wl,-z,stack-size=<VALUE IN BYTES> untuk meningkatkan ukuran tumpukan. Sebagai referensi, ukuran tumpukan default pada sebagian besar sistem GLIBC adalah 2MB.

Catatan tambahan

Anda dapat membuat koneksi administrator khusus (DAC) menggunakan autentikasi SQL Server dan host,port. Anggota peran Sysadmin pertama-tama perlu menemukan port DAC. Lihat Koneksi Diagnostik untuk Administrator Database untuk menemukan caranya. Misalnya, jika port DAC adalah 33000, Anda dapat menyambungkannya dengan sqlcmd sebagai berikut:
```
sqlcmd -U <user> -P <pwd> -S <host>,33000
```
Catatan

Koneksi DAC harus menggunakan Autentikasi SQL Server.
Manajer driver UnixODBC mengembalikan "pengidentifikasi atribut/opsi yang tidak valid" untuk semua atribut pernyataan saat diteruskan melalui SQLSetConnectAttr. Di Windows, ketika SQLSetConnectAttr menerima nilai atribut pernyataan, itu menyebabkan driver mengatur nilai tersebut pada semua pernyataan aktif, yang merupakan turunan dari handel koneksi.
Saat menggunakan driver dengan aplikasi yang sangat multithreaded, validasi handel unixODBC mungkin menjadi hambatan performa. Dalam skenario seperti itu, performa yang lebih tinggi dapat diperoleh dengan mengkompilasi unixODBC dengan --enable-fastvalidate opsi . Namun, berhati-hatilah bahwa opsi ini dapat menyebabkan aplikasi yang meneruskan handel yang tidak valid ke API ODBC mengalami crash alih-alih mengembalikan SQL_INVALID_HANDLE kesalahan.

Lihat Juga

Pertanyaan Umum
Masalah yang Diketahui dalam Versi Driver ini
Catatan Rilis

Bagikan melalui