V souladu s mým komentářem výše a odpovědí Yawara si nejsem vědom toho, že by Pass Through Queries bylo možné upravovat/aktualizovat. Jsou upravitelné v tom smyslu, že můžete upravit uložený objekt Pass Through Query, ale nevěřím, že je možné, aby Pass Through Query vytvořil editovatelnou sadu záznamů.
V zásadě existují dva způsoby, jak připojit Access ke zdroji dat bez přístupu.
První a nejoblíbenější metodou je použití nějaké formy propojených tabulek, obecně propojených tabulek ODBC. Existuje celá řada metod použití propojených tabulek ODBC s MS Access, ale podle toho, co většina vývojářů preferuje, je použití připojení bez DSN, která se obnoví nebo znovu vytvoří (odstraňují a znovu připojují) v době spuštění aplikace. Uvědomte si, že když používáte ODBC, stále používáte také DAO. DAO je výchozí objekt pro přístup k datům zabudovaný do MS Access a i když konkrétně nenapíšete žádný kód DAO, MS Access stále používá DAO pod kapotou k propojení vašich formulářů, sestav a dotazů s vaším zdrojem dat. V případě ODBC vlastně skončíte tím, že v práci fungují dvě vrstvy přístupu k datům, DAO a ODBC. Ale můžete používat ODBC/DAO s docela slušným výkonem a bez psaní kódu (kromě údržby propojených tabulek ODBC).
Druhou metodou je použití ADO. Na rozdíl od všeobecného přesvědčení to neznamená, že musíte používat nesvázané formuláře. Znamená to však, že musíte napsat více kódu než pomocí serveru JET/DAO/MSAccess nebo DAO/ODBC/SSQL. Musíte napsat kód, který přenese záznamy z databáze do sady záznamů ADO a poté pomocí kódu svázat formulář s touto sadou záznamů. Musíte napsat více kódu, abyste udrželi podřízené formuláře v synchronizaci s nadřazenými formuláři, abyste vložili cizí klíče do podřízených formulářů při vytváření nových záznamů a pro řadu dalších věcí, jako je filtrování a řazení jako vestavěné filtrování a třídění formuláře. možnosti obvykle nefungují se sadami záznamů ADO. ADO je skvělý způsob, jak hovořit s SQL Serverem, protože vám dává opravdu hodně kontroly, ale protože je náročný na kód a protože ODBC Linked Tables fungují tak dobře, většina vývojářů nedoporučuje používat ADO, pokud neexistuje jiný způsob, jak to udělat. chceš dělat. Jedním z příkladů je volání uložených procedur. Věřím, že Pass Through Queries lze použít k volání uložených procedur, ale také si myslím, že tam jsou určitá omezení (jako je použití parametrů). Věřím, že ve většině případů vývojáři používají ADO k volání uložených procedur. Hodně používám ADO, ale moc nepoužívám uložené procedury (zatím ne), takže o tom moc informací nemám.
Další věc, která stojí za zmínku, je, že DAO s ODBC používá „líné načítání“, ale ADO vás nutí stahovat všechna data, což může být velmi časově náročné a spotřebovávat spoustu paměti, pokud máte> miliony řádků. Nebo budete muset implementovat nějaký druh stránkování.
Moje vlastní funkce pro vytvoření jedné propojené tabulky ODBC bez DSN je uvedena níže. Pokud s Accessem a VBA začínáte, pravděpodobně vám to nebude dávat velký smysl. Kód odstraní jakoukoli definici tabulky, která již existuje pro tabulku, kterou se pokoušíte propojit, což je trochu nebezpečné, protože se domnívám, že by to mohlo odstranit místní, nepropojenou tabulku, kterou byste nechtěli. Zpracování chyb zde také není příliš rychlé, ale většina online ukázkových kódů v sobě nemá dobré zpracování chyb kvůli komplikacím, které s tím souvisí. Vytvoření indexů primárního klíče v propojené tabulce není vždy nutné. Mám to zabudované ve své funkci, protože jsem to potřeboval jednou pro konkrétní projekt, takže teď to tam nechávám a používám to v dobrém i ve zlém.
Chcete-li správně používat tento kód, opravdu potřebujete mít někde seznam všech vašich propojených tabulek a iterovat tento seznam a volat tuto funkci pro každou tabulku. Tato funkce umožňuje propojit tabulku pomocí jiného názvu, než je skutečný název na serveru SQL. Musíte mít také způsob, jak vytvořit platný připojovací řetězec ODBC, který musí být předán i této funkci.
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
Existuje několik opravdu dobrých zdrojů, které byste si měli prohlédnout ohledně DAO, ADO, Pass Through Queries, SQL Server atd.:
http://technet.microsoft.com /cs-us/library/bb188204%28v=sql.90%29.aspx
http://www.utteraccess.com/wiki/Choosing_between_DAO_and_ADO
Zde je příklad vazby formuláře na sadu záznamů ADO. Je to však trochu zavádějící, protože je nejlepší mít objekt globálního připojení, který zůstane otevřený během běhu aplikace. To umožňuje používat sady záznamů ADO, které jsou automaticky aktualizovatelné. Použití tohoto postupu může také změnit vaši sadu záznamů na objekt na úrovni formuláře.
http://msdn.microsoft .com/en-us/library/office/bb243828%28v=office.12%29.aspx