VBAプロジェクトからSQL Serverデータベースに直接アクセスする方法はすべて廃止されているようです。
私は何を取りこぼしたか? VBAからSQL Serverデータベースにアクセスするための公式のMicrosoft承認済みの方法は何ですか(つまり、非推奨非推奨であり、公式の開発言語です) Office 2013に含まれています)?
私は何を取りこぼしたか?
プレーンな古いODBC。 Access以外のOfficeアプリケーションのVBAプロジェクトでは、ODBC via ADOが最も簡単です:
Sub AdoOdbcExample()
Dim con As Object
Set con = CreateObject("ADODB.Connection")
con.Open _
"Driver={SQL Server Native Client 11.0};" & _
"Server=.\SQLEXPRESS;" & _
"Database=myDb;" & _
"Trusted_Connection=yes;"
con.Execute "UPDATE Clients SET FirstName='Gord' WHERE ID=5;"
con.Close
Set con = Nothing
End Sub
AccessのVBAプロジェクトでは、ODBCリンクテーブルと、常に持っているようなACE DAOを介したパススルークエリを使用するオプションもあります。
Sub DaoOdbcExample()
Dim cdb As DAO.Database, qdf As DAO.QueryDef
Set cdb = CurrentDb
Set qdf = cdb.CreateQueryDef("")
qdf.Connect = "ODBC;" & _
"Driver={SQL Server Native Client 11.0};" & _
"Server=.\SQLEXPRESS;" & _
"Database=myDb;" & _
"Trusted_Connection=yes;"
qdf.sql = "UPDATE Clients SET FirstName='Gord' WHERE ID=5;"
qdf.ReturnsRecords = False
qdf.Execute dbFailOnError
Set qdf = Nothing
Set cdb = Nothing
End Sub
ノート:
SQL Server Native Client 11.0は、SQL Server 2014に同梱されているバージョンです(参照: こちら )。
廃止されたデータアクセステクノロジの引用リスト は、「DAO 3.6はこのテクノロジの最終バージョンです。64ビットのWindowsオペレーティングシステムでは使用できません。」と述べています。 JetDAO( "Microsoft DAO 3.6 Object Library")を指します。 [〜#〜] ace [〜#〜]DAO(「Microsoft Office 14.0 Accessデータベースエンジンオブジェクトライブラリ」)は、64ビットアプリケーションで実際に使用できます64ビットバージョンのAccessデータベースエンジンがインストールされている場合。
正しい将来の方法は、ACEオブジェクトモデルを使用することです。ネイティブのoleDBがSQLサーバーから削除されていることは100%正しいです。 「一般的な」開発者コミュニティが.netが出てきたときにADOがドロップし始めたことに注意することも非常に重要です(ado.netプロバイダーはまったく異なる獣であり、oleDBに依存しないものですが、 sqlprovider)。
このため、この業界では大きなトレンドが発生しています。
OleDBから離れます。これは一般にWindowsのみのテクノロジーです。 iPad、スマートフォン、Androidなどの台頭により、そのようなプラットフォーム固有のプロバイダーもoleDBもなくなりました。そのため、オープンデータベースコネクティビティ標準を使用して現在の状態に戻す必要があります。 (ODBC)Oracle、Microsoft、MySQLはすべて、これが将来の道であり、選択であると述べています。
JETは廃止されたと見なされていますが、ACEは廃止されていません。
Access 2007(完全に3つのバージョンになりました)以降、DAOへの参照はありませんし、すべきではありません。したがって、Accessの最後の3つのバージョンでは、DAOオブジェクトライブラリへの参照を必要とせず、使用する必要もありません。
新しい組み込みのACEデータベースエンジンを使用する必要があります。つまり、DAOへの個別の参照は必要ありません。
ACEエンジンにはいくつかの利点があります。
DAO参照はもう必要ありません。
データエンジンへの参照が行われると、前の2つのライブラリ参照が処理されます。
X32ビット版とx64ビット版の両方が利用可能です(.netアプリケーションなどは、このデータエンジンのx64ビット版を使用できます)。 JETはx32ビットのみでした。
ACEプロバイダーは、引き続き更新と機能強化を受け取ります。 JETについても、ADOについても同様です。
ACEは、ストアプロシージャとテーブルトリガーをサポートするようになりました。また、WebサービスベースのSharePointリストもサポートしています。
SQL Azureと連携するようにAccess/ACEにも変更が加えられました。
SQLサーバーでAccessを使用するには、ACEとリンクテーブルを使用するだけです。前述のように、ADO=から離れる傾向は、.netが登場した約13年前に始まりました。
したがって、標準的なアプローチと今推奨されるのはACE + odbcです。
だから、ここで何も見逃していません。混乱は、状態JETが減価償却されたという記事に由来しますが、THE LAST 3バージョンのAccessは現在JETを使用せず、ACEと呼ばれる新しいライブラリを使用するという非常に重要な詳細を省略しています。
アクセスアプリケーションでDAOへの参照が不要になった、または不要になったことは重要です。
あなたは確かに互換性のあるDAOライブラリを使用しており、reocrdsetコードの前にDAOを付けることをお勧めします(そのため、過去にこれを行った場合、または宣言時に常にDAO修飾子を省略した場合、古い既存のコードは問題なく機能しますレコードセット。
Sql passなどの場合は、保存されたpass throughクエリを使用してこれを行うことができます。
CurrentDb.QueryDefs("MyPass").Execute
または、いくつかのt-sqlについては、これを行うことができます:
With CurrentDb.QueryDefs("MyPass")
.SQL = "ALTER TABLE Contacts ADD MiddleName nvarchar(50) NULL"
.Execute
End If
または、パラメータを使用して「オンザフライ」で選択したストアプロシージャを呼び出す
With CurrentDb.QueryDefs("MyPass")
.SQL = "Exec MyStoreProc " & strMyParm1
.Execute
End If
上記はそれほどきれいではありませんか?前述のように、上記のコード例はFARが少ないコードになりがちで、投稿されたoleDB/ADOの例を使用する場合は面倒です。
ODBCとsqlサーバーを中心にスキルを磨いたAccessの長い間、何もする必要はありません。業界がずっとずっとやってきたことが推奨されるアプローチであるためです。
JET-DIRECTはACEでサポートされていませんが、JETダイレクトの代わりに上記のパススルーquerydefの例を使用してこの選択が失敗した場合は考えられません。
Vbaでadodb.connectionを初期化すると、
.Provider = "sqloledb" .Properties("Data Source").Value = sServer .Properties("Initial Catalog").Value = sDB .Properties("Integrated Security").Value = "SSPI"
と
.ConnectionString = _ "DRIVER={ODBC Driver 11 for SQL Server}; " & _ "SERVER=" & sServer & "; " & _ "Trusted_Connection=Yes; " & _ "DATABASE=" & sDB & "; "
これは.Provider = "MSDASQL.1"を使用していますが、追加する必要はありません。