Zgodnie z moim komentarzem powyżej i odpowiedzią Yawara, nie jestem świadomy, że zapytania typu Pass Through są kiedykolwiek edytowalne/aktualizowane. Można je edytować w tym sensie, że można edytować zapisany obiekt zapytania przekazującego, ale nie wierzę, że zapytanie przekazujące może utworzyć edytowalny zestaw rekordów.
Zasadniczo istnieją dwie metody łączenia Access ze źródłem danych innym niż Access.
Pierwsza i najbardziej popularna metoda polega na użyciu jakiejś formy tabel połączonych, zazwyczaj tabel połączonych ODBC. Istnieje wiele metod korzystania z tabel połączonych ODBC z MS Access, ale większość programistów preferuje korzystanie z połączeń bez DSN, które są odświeżane lub przebudowywane (usuwane i ponownie podłączane) w momencie uruchamiania aplikacji. Pamiętaj, że korzystając z ODBC, nadal korzystasz z DAO. DAO jest domyślnym obiektem dostępu do danych wbudowanym w MS Access i nawet jeśli nie piszesz specjalnie żadnego kodu DAO, MS Access nadal używa DAO pod maską do łączenia formularzy, raportów i zapytań ze źródłem danych. W przypadku ODBC w efekcie mamy do czynienia z dwiema warstwami dostępu do danych, DAO i ODBC. Ale możesz używać ODBC/DAO z całkiem przyzwoitą wydajnością i bez pisania kodu (poza utrzymaniem połączonych tabel ODBC).
Drugą metodą jest użycie ADO. Wbrew powszechnemu przekonaniu nie oznacza to, że musisz używać formularzy niezwiązanych. Ale oznacza to, że musisz napisać więcej kodu niż przy użyciu JET/DAO/MSAccess lub DAO/ODBC/SSQL Server. Musisz napisać kod, aby wprowadzić rekordy z bazy danych do i ADO Recordset, a następnie użyć kodu, aby powiązać formularz z tym Recordset. Musisz napisać więcej kodu, aby zsynchronizować formularze podrzędne z formularzami nadrzędnymi, aby wstawić klucze obce do formularzy podrzędnych podczas tworzenia nowych rekordów, a także do wielu innych rzeczy, takich jak filtrowanie i sortowanie jako wbudowane filtrowanie i sortowanie formularza opcje zwykle nie działają z zestawami rekordów ADO. ADO to świetny sposób na komunikowanie się z SQL Server, ponieważ zapewnia on naprawdę dużą kontrolę, ale ponieważ jest intensywny w kodzie i ponieważ tabele połączone ODBC działają tak dobrze, większość programistów nie zaleca korzystania z ADO, chyba że nie ma innego sposobu na zrobienie tego chcesz robić. Jednym z przykładów jest wywoływanie procedur składowanych. Uważam, że Pass Through Queries może być używany do wywoływania Stored Procedures, ale myślę też, że istnieją tam pewne ograniczenia (takie jak używanie parametrów). Uważam, że w większości przypadków programiści używają ADO do wywoływania procedur składowanych. Dużo używam ADO, ale nie używam zbyt wiele procedur przechowywanych (jeszcze nie), więc nie mam zbyt wielu informacji na ten temat.
Inną rzeczą, o której warto wspomnieć, jest to, że DAO z ODBC używa „leniwego ładowania”, ale ADO zmusza cię do pobrania wszystkich danych, co może być bardzo czasochłonne i pochłaniać dużo pamięci, jeśli masz> miliony wierszy. Albo będziesz musiał zaimplementować jakiś rodzaj stronicowania.
Poniżej znajduje się moja własna funkcja tworzenia pojedynczej połączonej tabeli DSN-less ODBC. Jeśli jesteś nowy w Accessie i VBA, prawdopodobnie nie będzie to miało dla Ciebie większego sensu. Kod usuwa każdą definicję tabeli, która już istnieje dla tabeli, którą próbujesz połączyć, co jest trochę niebezpieczne, ponieważ uważam, że może usunąć lokalną, niepołączoną tabelę, której nie chcesz. Obsługa błędów tutaj również nie jest zbyt szybka, ale większość przykładowego kodu online nie ma dobrej obsługi błędów z powodu komplikacji, które się z tym wiążą. Tworzenie indeksów klucza podstawowego w tabeli połączonej nie zawsze jest konieczne. Po prostu mam to wbudowane w moją funkcję, ponieważ kiedyś potrzebowałem go do konkretnego projektu, więc teraz go tam zostawiam i używam, na dobre lub na złe.
Aby właściwie wykorzystać ten kod, naprawdę musisz mieć gdzieś listę wszystkich połączonych tabel i iterować po tej liście i wywoływać tę funkcję dla każdej tabeli. Ta funkcja umożliwia połączenie tabeli przy użyciu innej nazwy niż jej rzeczywista nazwa w SQL Server. Musisz także mieć sposób na zbudowanie prawidłowego ciągu połączenia ODBC, który również musi zostać przekazany do tej funkcji.
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
Istnieje kilka naprawdę dobrych zasobów dotyczących DAO, ADO, Pass Through Queries, SQL Server itp.:
http://technet.microsoft.com /pl-pl/library/bb188204%28v=sql.90%29.aspx
http://www.utteraccess.com/wiki/Choosing_between_DAO_and_ADO
Oto przykład powiązania formularza z ADO Recordset. Jest to jednak trochę mylące, ponieważ najlepiej jest mieć globalny obiekt połączenia, który pozostaje otwarty podczas działania aplikacji. Pozwala to na używanie zestawów rekordów ADO, które można automatycznie aktualizować. Zastosowanie tej praktyki może również sprawić, że Twój zestaw rekordów stanie się obiektem na poziomie formularza.
http://msdn.microsoft .com/en-us/library/office/bb243828%28v=office.12%29.aspx
