Pedoman Pemrograman

Unduh driver ODBC

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 Active Result Sets (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:

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 (didokumentasikan 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 di salah satu set/pengodean karakter berikut didukung:

Catatan

iconv Karena perbedaan dan muslglibc banyak dari 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 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 adalah 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 khas di mana pengodeannya adalah UTF-8, pengguna ODBC Driver 17 yang ditingkatkan 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() kebutuhan untuk 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 default (biasanya codepage 1252) SQL Server pengodean. 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 pada 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 kolab 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 dari 0x05BA. Di macOS dan Linux dengan versi libiconv yang lebih lama dari 1.15, versi ini 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 pendekodean karakter yang awalnya tidak didefinisikan dalam standar pengodean juga berbeda. Misalnya, byte 0x80 dikonversi ke U+0080 di Windows tetapi dapat 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 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 yang 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 untuk -Wl,-z,stack-size=<VALUE IN BYTES> 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, hal ini 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 dapat menjadi penyempitan 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

Tanya Jawab Umum
Masalah yang Diketahui dalam Versi Driver ini
Catatan Rilis