In Übereinstimmung mit meinem obigen Kommentar und der Antwort von Yawar ist mir nicht bekannt, dass Pass-Through-Abfragen jemals bearbeitet/aktualisiert werden können. Sie sind in dem Sinne bearbeitbar, dass Sie ein gespeichertes Pass-Through-Abfrageobjekt bearbeiten können, aber ich glaube nicht, dass es für eine Pass-Through-Abfrage möglich ist, ein bearbeitbares Recordset zu erzeugen.
Es gibt grundsätzlich zwei Methoden, um Access mit einer Nicht-Access-Datenquelle zu verbinden.
Die erste und beliebteste Methode besteht darin, eine Form von verknüpften Tabellen zu verwenden, im Allgemeinen ODBC-verknüpfte Tabellen. Es gibt eine Vielzahl von Methoden zur Verwendung von ODBC-verknüpften Tabellen mit MS Access, aber die meisten Entwickler bevorzugen die Verwendung von DSN-losen Verbindungen, die aktualisiert oder neu erstellt (gelöscht und neu verbunden) werden, wenn Ihre Anwendung gestartet wird. Beachten Sie, dass Sie bei Verwendung von ODBC immer noch DAO verwenden. DAO ist das standardmäßig in MS Access integrierte Datenzugriffsobjekt, und selbst wenn Sie keinen speziellen DAO-Code schreiben, verwendet MS Access immer noch DAO im Hintergrund, um Ihre Formulare, Berichte und Abfragen mit Ihrer Datenquelle zu verknüpfen. Im Fall von ODBC haben Sie am Ende tatsächlich zwei Datenzugriffsschichten am Werk, DAO und ODBC. Aber Sie können ODBC/DAO mit ziemlich anständiger Leistung und ohne Code zu schreiben verwenden (außer um die mit ODBC verknüpften Tabellen zu verwalten).
Die zweite Methode ist die Verwendung von ADO. Entgegen der landläufigen Meinung bedeutet dies nicht, dass Sie ungebundene Formulare verwenden müssen. Dies bedeutet jedoch, dass Sie mehr Code schreiben müssen, als wenn Sie JET/DAO/MSAccess oder DAO/ODBC/SSQL Server verwenden. Sie müssen Code schreiben, um Datensätze aus Ihrer Datenbank in ein ADO-Recordset einzufügen, und dann Code verwenden, um Ihr Formular an dieses Recordset zu binden. Sie müssen mehr Code schreiben, um untergeordnete Formulare mit übergeordneten Formularen synchron zu halten, um Fremdschlüssel in untergeordnete Formulare einzufügen, wenn neue Datensätze erstellt werden, und auch für eine Vielzahl anderer Dinge wie das Filtern und Sortieren als das integrierte Filtern und Sortieren des Formulars Optionen funktionieren normalerweise nicht mit ADO-Recordsets. ADO ist eine großartige Möglichkeit, mit SQL Server zu kommunizieren, da es Ihnen wirklich viel Kontrolle gibt, aber weil es codeintensiv ist und ODBC-verknüpfte Tabellen so gut funktionieren, empfehlen die meisten Entwickler die Verwendung von ADO nicht, es sei denn, es gibt keine andere Möglichkeit, was zu tun du willst machen. Ein Beispiel hierfür ist das Aufrufen von Stored Procedures. Ich glaube, dass Pass-Through-Abfragen verwendet werden können, um gespeicherte Prozeduren aufzurufen, aber ich denke auch, dass es dort einige Einschränkungen gibt (z. B. die Verwendung von Parametern). Ich glaube, dass Entwickler in den meisten Fällen ADO verwenden, um gespeicherte Prozeduren aufzurufen. Ich benutze ADO viel, aber ich benutze Stored Procedures nicht oft (noch nicht), also habe ich nicht viele Informationen darüber.
Eine andere erwähnenswerte Sache ist, dass DAO mit ODBC "Lazy Loading" verwendet, ADO Sie jedoch dazu zwingt, alle Daten abzurufen, was sehr zeitaufwändig sein und viel Speicher verbrauchen kann, wenn Sie> Millionen von Zeilen haben. Andernfalls müssen Sie eine Art Paging implementieren.
Meine eigene Funktion zum Erstellen einer einzelnen DSN-Less ODBC Linked-Tabelle ist unten. Wenn Sie neu bei Access und neu bei VBA sind, wird dies wahrscheinlich nicht viel Sinn für Sie machen. Der Code löscht alle Tabellendefinitionen, die bereits für die Tabelle vorhanden sind, die Sie verknüpfen möchten, was ein wenig gefährlich ist, da ich glaube, dass dadurch eine lokale, nicht verknüpfte Tabelle gelöscht werden könnte, die Sie nicht möchten. Die Fehlerbehandlung hier ist auch nicht wirklich auf dem neuesten Stand, aber der meiste Online-Beispielcode hat wegen der damit verbundenen Komplikationen keine gute Fehlerbehandlung. Die Erstellung von Primärschlüsselindizes für eine verknüpfte Tabelle ist nicht immer erforderlich. Ich habe es nur in meine Funktion eingebaut, weil ich es einmal für ein bestimmtes Projekt brauchte, also lasse ich es jetzt dort und verwende es, zum Guten oder zum Schlechten.
Um diesen Code richtig zu nutzen, müssen Sie wirklich irgendwo eine Liste aller Ihrer verknüpften Tabellen haben und diese Liste durchlaufen und diese Funktion für jede Tabelle aufrufen. Mit dieser Funktion können Sie die Tabelle unter einem anderen Namen als dem tatsächlichen Namen in SQL Server verknüpfen. Sie müssen auch eine Möglichkeit haben, eine gültige ODBC-Verbindungszeichenfolge zu erstellen, die auch an diese Funktion übergeben werden muss.
Private Sub LinkODBCTable(sSourceTableName As String, _
sLocalTableName As String, _
sPrimaryKeyField As String, _
sConString As String)
Dim dbCurrent As DAO.Database
Dim tdfCurrent As DAO.TableDef
Set dbCurrent = DBEngine.Workspaces(0).Databases(0)
On Error Resume Next
'Be Careful, this could delete a local, non-linked table.
dbCurrent.TableDefs.Delete sLocalTableName
If Err.Number <> 0 Then
If Err.Number = 3011 Then
'Table does not exist
Else
MsgBox "Error in LinkODBCTable" & vbCrLf & vbCrLf & Err.Number & " " & Err.Description
End If
Err.Clear
End If
On Error GoTo 0
Set tdfCurrent = dbCurrent.CreateTableDef(sLocalTableName)
tdfCurrent.Connect = sConString
tdfCurrent.sourceTableName = sSourceTableName
dbCurrent.TableDefs.Append tdfCurrent
On Error Resume Next
If sPrimaryKeyField <> "" Then
dbCurrent.Execute "CREATE INDEX __UniqueIndex ON [" & sLocalTableName & "] (" & sPrimaryKeyField & ")", dbFailOnError
If Err.Number <> 0 Then
If Err.Number = 3283 Then
'Primary Key Already Exists
Else
MsgBox "Error in LinkODBCTable" & vbCrLf & vbCrLf & Err.Number & " " & Err.Description
End If
Err.Clear
End If
End If
Set tdfCurrent = Nothing
Set dbCurrent = Nothing
End Sub
Es gibt ein paar wirklich gute Ressourcen, die Sie in Bezug auf DAO, ADO, Pass-Through-Abfragen, SQL Server usw. überprüfen sollten:
http://technet.microsoft.com /en-us/library/bb188204%28v=sql.90%29.aspx
http://www.utteraccess.com/wiki/Auswahl_zwischen_DAO_und_ADO
Hier ist ein Beispiel für die Bindung eines Formulars an ein ADO-Recordset. Es ist jedoch ein wenig irreführend, da es am besten ist, ein globales Verbindungsobjekt zu haben, das während der Laufzeit der Anwendung geöffnet bleibt. Dadurch können Sie automatisch aktualisierbare ADO-Datensätze verwenden. Die Verwendung dieser Vorgehensweise könnte Ihr Recordset auch zu einem Objekt auf Formularebene machen.
http://msdn.microsoft .com/en-us/library/office/bb243828%28v=office.12%29.aspx
