LinuxおよびmacOSでのODBCに関するよくある質問

ODBC ドライバーのダウンロード

この記事では、Linux および macOS 上の SQL Server 向け Microsoft ODBC ドライバーのインストール、接続、およびアプリケーション開発に関するよくある質問に答えます。

ドライバーについて

どのODBCドライバーバージョンを使うべきでしょうか?

新しい開発には、現在のドライバー ラインである SQL Server 用 Microsoft ODBC Driver 18 を使用してください。 Microsoft ODBC Driver 17 for SQL Serverは、サポート ライフサイクルで説明されているとおり、既にこれを導入しているアプリケーションについては引き続きサポートされます。

ほとんどのアプリケーションに影響を与えるアップグレードの変更点は、ドライバー18がデフォルトで接続を暗号化することです。 すべての違いについては、 メジャーバージョンの違いを参照してください。

ドライバーはどのオペレーティングシステムやプロセッサアーキテクチャをサポートしていますか?

ドライバー18は以下のオペレーティングシステムおよびプロセッサアーキテクチャをサポートしています:

オペレーティング システム x64 のサポート Arm64 のサポート
Alpine Linux はい Driver 18.3以降
Azure Linux はい ドライバー 18.6.1 以降
Debian はい ドライバー 18.1 以降
Oracle Linux はい No
Red Hat Enterprise Linux はい ドライバー 18.1 以降
SUSE Linux Enterprise Server はい No
Ubuntu はい Driver 18.1以降
macOS はい ドライバー 17.8 以降

サポートされているOSのバージョンは、ドライバーのリリースごとに変わります。 バージョン別の表については「システム要件」を参照してください。

LinuxとmacOSのドライバーはどのSQL Server機能をサポートしていますか?

LinuxおよびmacOSのドライバーはほとんどのSQL Server機能をサポートしています。 SQL_ATTR_ENLIST_IN_DTC属性、データベースミラーリング、FILESTREAM、またはドライバーのパフォーマンスプロファイリング属性を通じた分散トランザクションへの参加はサポートしていません。 LocalDBはLinuxやmacOSでは利用できません。 分散トランザクションコーディネーター(DTC)を通じたXAトランザクションは、ドライバー17.3からサポートされています。 詳細については、DTC で XA トランザクションを使用するをご覧ください。 完全なリストについては 「制限」を参照してください。

ドライバーはオープンソースですか?

No. MicrosoftのODBCドライバー(SQL Server)はオープンソースではありません。

インストールと構成

ドライバーはどのドライバーマネージャーを使っていますか?

ドライバーはunixODBCドライバーマネージャーを使用しています。 プラットフォームのパッケージマネージャーやHomebrewでDriver 17や18をインストールすると、unixODBCは依存関係としてインストールされます。 LinuxやmacOSの手順に従ってください。

macOSでは、iODBCではなくunixODBCでアプリケーションを構築し実行してください。 アプリケーション、ドライバーマネージャー、ドライバーのプロセッサアーキテクチャを一致させます。 incompatible architecture (have 'arm64', need 'x86_64')のようなエラーはアーキテクチャの不一致を示しており、必ずしもドライバーマネージャーの誤りではありません。

どのドライバーがインストールされているか、どの設定ファイルが使われているかはどうやって確認すればいいですか?

odbcinst -q -dを起動して登録ドライバーをリストアップしてください。 出力は各ドライバー名を、接続文字列でそのとおりに記述する必要がある表記どおりに示します:

[ODBC Driver 18 for SQL Server]

odbcinst -j を実行すると、unixODBC のバージョンと、ドライバーを登録する odbcinst.ini、システムおよびユーザーのデータソース名 (DSN) を保持する odbc.ini のパスが表示されます:

unixODBC 2.3.11
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/<user>/.odbc.ini

DSNの設定については、「 接続文字列とDSN」を参照してください。

なぜドライバーマネージャーはドライバーライブラリを開けないと報告するのでしょうか?

エラーは次のように表示されます:

[01000][unixODBC][Driver Manager]Can't open lib 'ODBC Driver 18 for SQL Server' : file not found

以下の原因を順に確認してください:

  1. 接続文字列やDSNのDriver値は登録されたドライバー名と一致しません。 odbcinst -q -dを実行して、名前を正確にコピーしてください。
  2. あなたのアプリケーションは編集したものとは異なる設定ファイルを使っています。 アプリケーションと同じ環境から odbcinst -j を実行し、アプリケーションがどのドライバーマネージャーを読み込むか確認してください。 macOSでは、macOSでのトラブルシューティングで説明されているように、アプリケーションで必要な場合にのみ設定用のシンボリックリンクを作成してください。
  3. unixODBCドライバーマネージャーが複数インストールされていて、アプリケーションが間違ったものを読み込んでしまいます。 Linux では、 find /usr -name 'libodbc*.so*'を実行します。 macOS では find /opt/homebrew /usr/local -name 'libodbc*.dylib' を実行します。 複数のパスだけでは複数のドライバーマネージャーがインストールされていることを証明できません。HomebrewのリンクはCellarディレクトリ内の同じライブラリを指し示すことがあります。 アプリケーションが実際に読み込むライブラリを確認してください。 詳細については、接続問題のトラブルシューティングをご覧ください。

接続と認証

なぜドライバー17で動作する接続が、ドライバー18で証明書エラーで失敗するのでしょうか?

ドライバー18 の既定値は Encrypt=yes です。 ドライバー17は、非空のEncrypt=no設定またはアクセストークンが提供されていない場合にのみ、Authenticationがデフォルトとなります。 空でないAuthentication=SqlPassword設定(Authenticationを含む)またはアクセストークンは、ドライバー 17 の既定値をEncrypt=yesに変更します。 明示的な暗号化設定はこれらのデフォルトを上書きします。

SQLSetConnectAttrで設定した接続文字列、DSN、プリコネクション属性の有効設定を確認してください。 例えば、DSN内のSQL_COPT_SS_ENCRYPT=SQL_EN_ONまたはEncrypt=yesは、接続文字列でEncryptが省略されている場合でも暗号化を要求します。 アクセストークンは SQL_COPT_SS_ACCESS_TOKEN 接続属性を通じてのみ指定し、接続文字列キーワードは使わないでください。

Encrypt=yesとTrustServerCertificate=noでは、両ドライバーが接続を暗号化し、サーバー証明書を検証します。 Encrypt=no の場合、ドライバー 17 は証明書の検証を行いませんが、サーバーが暗号化を強制し、かつ TrustServerCertificate=no の場合、ドライバー 18 は証明書の検証を行います。 以前にDriver 17 Encrypt=no の既定設定を使っていた接続は、自己署名または信頼できない証明書を持つサーバーに対してDriver 18で失敗する可能性があります。 自己署名証明書の場合、ドライバー18エラーは以下の通りです。

[Microsoft][ODBC Driver 18 for SQL Server]SSL Provider: [error:0A000086:SSL routines::certificate verify failed:self-signed certificate]
[Microsoft][ODBC Driver 18 for SQL Server]Client unable to establish connection. For solutions related to encryption errors, see https://go.microsoft.com/fwlink/?linkid=2226722

信頼できる証明書または証明書ピンニングを使用してください。 以下のオプションをご利用ください:

  • クライアントが信頼する証明書発行機関が発行する証明書をサーバーにインストールしてください。 証明書は信頼されているが、その名前が Server 値と一致しない場合は、 HostNameInCertificate を証明書内の名前に設定してください。 HostNameInCertificate は期待される名前だけを変更するため、自己署名証明書の問題は解決されません。
  • ドライバー 18.1 以降のバージョンと Tabular Data Stream (TDS) 8.0 をサポートするサーバーを使用する場合は、Encrypt=strict および ServerCertificate に、サーバーの証明書のコピーのパスを指定してください。 その後、ドライバーはその証明書そのもののみを受け入れます。 ServerCertificate 厳格モードでのみ動作します。
  • サーバーが暗号化を強制しない場合に暗号化されていないアプリケーショントラフィックを受け入れる場合にのみ Encrypt=no を設定してください。 これは、非空の Authentication 設定やアクセストークンが提供されておらず、暗号化オーバーライドが設定されていない場合にのみ、ドライバー17のデフォルトと一致します。 サーバーが暗号化を強制する場合、TrustServerCertificate=yes で検証が無効にされていない限り、ドライバー 18 は引き続き証明書の検証を行います。

Caution

TrustServerCertificate=yes は暗号化を有効にしません。 Encrypt=yes を使用すると、トラフィックを暗号化したまま証明書の検証をバイパスしてしまうため、中間者攻撃の標的となる可能性があります。 Encrypt=noでは、アプリケーショントラフィックはサーバーが強制的に暗号化しない限り暗号化されません;サーバーが暗号化を強制した場合、証明書検証はバイパスされます。 Encrypt=strictでは、ドライバーはTrustServerCertificateを無視して証明書を検証するか、設定されている場合はServerCertificateと照合します。 信頼できる証明書または証明書ピンニングを優先してください。

詳細については、 デフォルトの暗号化動作をご覧ください。

ドライバーはKerberos認証に対応していますか?

はい。 kinitでKerberosのチケットを取得し、接続文字列またはDSNでTrusted_Connection=yesを指定して接続してください。 SQL Serverインスタンスには登録されたサービスプリンシパル名(SPN)が必要です。 設定手順については「 統合認証を使用」をご覧ください。

ドライバーはMicrosoft Entra ID認証をサポートしていますか?

はい、Azure SQL Database、Azure SQL Managed Instance、SQL Server 2022以降のバージョンで対応可能です。 SQL Server(Azure Arc経由を含む)を設定するには、Microsoft Entra認証(SQL Server)を使いましょう。 LinuxおよびmacOSでは、Driver 17以降のバージョンが以下の方法をサポートしています:

  • ドライバー 17.3 以降、Authentication=ActiveDirectoryMsi によるマネージド ID が利用可能になります。
  • サービスプリンシパル (Authentication=ActiveDirectoryServicePrincipal 付き)、ドライバー 17.7 以降。
  • ドライバー 17.6 以降、Authentication=ActiveDirectoryIntegrated との連携によるフェデレーション環境での Kerberos による統合認証。
  • アプリケーションが取得し、SQL_COPT_SS_ACCESS_TOKEN 接続属性を介して渡されるアクセストークン。

ActiveDirectoryInteractiveWindowsドライバーでのみ利用可能です。 ActiveDirectoryPassword は 非推奨です。 Linux や macOS のドライバーによって管理される認証は、条件付きアクセスポリシーを必要とするシナリオをサポートしていません。 もしアプリケーションが別途アクセストークンを取得する場合、認証ライブラリとMicrosoft Entra IDポリシーがそのトークン取得を管理します。 トークンを SQL_COPT_SS_ACCESS_TOKEN に渡します。

Alpine Linuxでは、統合認証にはSimple and Protected Generic Security Service Application Program Interface Negotiation Mechanism(SPNEGO)をサポートする libcurl ビルドが必要です。 デフォルトのパッケージが対応していると仮定するのではなく、インストール済みの libcurl 機能を確認してください。

接続文字列やコードサンプルについては、「ODBCドライバーでMicrosoft Entra IDを使う」をご覧ください。

開発とトラブルシューティング

既存のODBCアプリケーションはLinuxやmacOSでこのドライバーを利用できますか?

はい。 ODBCアプリケーションプログラミングインターフェース(API)に書かれ、unixODBCに対して構築されたアプリケーションはこのドライバーをロードできます。 SQL Server固有の機能を使用するには、unixODBCヘッダーの後にmsodbcsql.hを入れてください。 コンパイラコマンドやライブラリ名については、 ODBCドライバを使ったCおよびC++アプリケーションの開発を参照してください。

サンプル アプリケーションはありますか?

はい。 C++ と ODBC で接続してクエリを実行するでは、Linux、macOS、Windows でサンプルをビルドして実行します。

ODBCの呼び出しをどうやって追跡すればいいですか?

トレースファイルには機密データが含まれていることがあります。 アプリケーションを動かすアカウントとして、そのアカウントだけがアクセスできるディレクトリを作成してください:

mkdir -m 700 "$HOME/odbc-trace"

これらの設定を、odbcinst.ini の [ODBC] セクションに追加します。 /home/<user>/odbc-trace/odbctrace.logを、作成したディレクトリ内の絶対パスで置き換えてください。 macOSでは、ホームディレクトリは通常/Users/<user>ではなく/home/<user>を使用します。

unixODBCによる切り捨てを避けるために、トレースファイルパスの全パスは62バイト以下に保ちましょう。

[ODBC]
Trace = Yes
TraceFile = /home/<user>/odbc-trace/odbctrace.log

これらの設定により、このドライバー マネージャの構成を使用するアプリケーションのトレースが有効になりますが、トレースを行うとアプリケーションの処理速度が低下します。 各アプリケーションアカウントごとに別々のプライベートディレクトリを使いましょう。 終わったら Trace = Yes を削除し、不要なトレースファイルは削除してください。 アプリケーションごとのトレースについては、 LinuxおよびmacOSのデータアクセストレーシングを参照してください。

文字データ

アプリケーションはどのUnicodeエンコーディングを使うべきでしょうか?

SQLWCHARデータにはUTF-16LE(リトルエンディアン)を使ってください。 LinuxやmacOSでは、32ビットのネイティブSQLWCHAR型ではなく、ODBCワイド文字APIでUTF-16 wchar_tバッファを使用してください。

SQLCHARデータにはUTF-8を使用してください。 ドライバー 17 以降では、プロセス ロケールがそのいずれかを選択している場合、ドライバーは SQLCHAR データに対してシングルバイト コード ページとダブルバイト コード ページのセットも受け入れます。 プロセスは C ロケールで開始されるため、アプリケーションが setlocale を呼び出さない限り、ドライバは UTF-8 を使用します。 エンコーディングの一覧については、「 文字データの処理」を参照してください。