4

Windows 64 で動作するネイティブ C++ アプリケーションがありますが、ATL を使用しません (今後も使用しません)。アプリケーションからネットワーク経由で SQL Server 2012 に接続できるようにしたいと考えています。

次の要件があります。

  • パフォーマンスが鍵

  • C++ は、レコードを挿入するだけで (たとえば、Stored Procs を呼び出して)、他には何も挿入しません (選択、削除、更新は行いません)。

  • レコードの挿入はノンブロッキング (非同期) である必要があります。

上記の基準を満たしているため、OLE DB と ODBC に選択肢を絞り込みました。ただし、インターネットには、何を使用するかについて相反するアドバイスがたくさんあるようです。例:

私は本当に混乱しており、私の基準で SQL Server にアクセスするための最良のテクノロジについて、さらに意見を求めたいと思います。

4

2 に答える 2

4

OleDBとODBCはどちらもSQLNCLIを使用します。コンポーネント名とバージョン別のプロパティの表を参照してください。Sqlncli.dll/Sqlncli10.dll/Sqlncli11.dllがODBCとOleDBの両方のドライバーであることに注意してください。

データアクセステクノロジのロードマップを見ると、ODBCとOleDBの両方が最新でサポートされていることがわかります。非推奨となるのは、SQLOLEDBとSQLODBCです。これらは、OleDBとODBC用の古いMDAC SQL Serverドライブ（つまり、sqlsrv32.dllとSqloledb.dll）です。どちらにもアップグレードパスと推奨事項があります。MDACからSQLServerネイティブクライアントへのアプリケーションの更新を参照してください。

したがって、結論として、ODBCとOleDBの両方を安全に使用し続けることができます。古い、非推奨のMDACドライバーではなく、最新のSLNCLIベースのドライバーを使用するようにしてください。

非推奨のドライバーを使用する際の主なリスクは、新しいデータ型（geography、hierachy、datetime2など）のサポートがないことです。

于 2013-03-23T20:36:20.263 に答える
0

私は何年も前に OleDB (ATL を使用) と ODBC (MFC を使用) を経験しました。

しかし、インターフェイスがボトルネックになることはめったになく、通常は挿入/更新が時間の大半を占めます (実際、一括コピー + ストアド プロシージャを使用して大規模な挿入/更新を実行しました)。

とにかく、私は中間の (3 番目の?) 方法を提案します: C++ / ODBC を耐えられるようにするOTL 。

于 2013-03-23T20:46:54.403 に答える