Hoe maak je een passthrough / passthru-query bewerkbaar?

In lijn met mijn opmerking hierboven en het antwoord van Yawar, ben ik me er niet van bewust dat Pass Through-query's ooit kunnen worden bewerkt/bijgewerkt. Ze zijn bewerkbaar in die zin dat je een opgeslagen Pass Through Query-object kunt bewerken, maar ik geloof niet dat het mogelijk is voor een Pass Through Query om een bewerkbare recordset te produceren.

Er zijn in principe twee methoden om Access te verbinden met een niet-Access-gegevensbron.

De eerste en meest populaire methode is om een of andere vorm van gekoppelde tabellen te gebruiken, over het algemeen ODBC-gekoppelde tabellen. Er zijn verschillende methoden om ODBC-gekoppelde tabellen met MS Access te gebruiken, maar de meeste ontwikkelaars geven er de voorkeur aan om DSN-loze verbindingen te gebruiken die worden vernieuwd of opnieuw worden opgebouwd (verwijderd en opnieuw verbonden) op het moment dat uw toepassing wordt gestart. Houd er rekening mee dat wanneer u ODBC gebruikt, u ook nog steeds DAO gebruikt. DAO is het standaard gegevenstoegangsobject dat in MS Access is ingebouwd en zelfs als u niet specifiek een DAO-code schrijft, gebruikt MS Access nog steeds DAO onder de motorkap om uw formulieren, rapporten en query's aan uw gegevensbron te koppelen. In het geval van ODBC heb je eigenlijk twee datatoegangslagen op het werk, DAO en ODBC. Maar je kunt ODBC/DAO gebruiken met behoorlijk behoorlijke prestaties en zonder code te schrijven (behalve om de ODBC-gekoppelde tabellen te onderhouden).

De tweede methode is om ADO te gebruiken. In tegenstelling tot wat vaak wordt gedacht, betekent dit niet dat u ongebonden formulieren moet gebruiken. Maar het betekent wel dat je meer code moet schrijven dan met JET/DAO/MSAccess of DAO/ODBC/SSQL Server. U moet code schrijven om records uit uw database naar en ADO Recordset te brengen en vervolgens code gebruiken om uw formulier aan die Recordset te binden. U moet meer code schrijven om onderliggende formulieren synchroon te houden met bovenliggende formulieren, om externe sleutels in onderliggende formulieren in te voegen wanneer nieuwe records worden gemaakt, en voor een aantal andere dingen, zoals filteren en sorteren als de ingebouwde filtering en sortering van het formulier opties werken meestal niet met ADO-recordsets. ADO is een geweldige manier om met SQL Server te praten, omdat het je echt veel controle geeft, maar omdat het code-intensief is en omdat ODBC Linked Tables zo goed werken, raden de meeste ontwikkelaars het gebruik van ADO niet aan, tenzij er geen andere manier is om te doen wat Jij wilt doen. Een voorbeeld hiervan is het aanroepen van Stored Procedures. Ik geloof dat Pass Through-query's kunnen worden gebruikt om opgeslagen procedures aan te roepen, maar ik denk ook dat er enkele beperkingen zijn (zoals het gebruik van parameters). Ik geloof dat ontwikkelaars in de meeste gevallen ADO gebruiken om opgeslagen procedures aan te roepen. Ik gebruik ADO veel, maar ik gebruik Stored Procedures niet veel (nog niet), dus daar heb ik niet veel informatie over.

Een ander ding dat het vermelden waard is, is dat DAO met ODBC "lui laden" gebruikt, maar ADO dwingt je om alle gegevens op te halen, wat erg tijdrovend kan zijn en veel geheugen kan verbruiken als je> miljoenen rijen hebt. Anders moet je een soort van paging implementeren.

Mijn eigen functie om een enkele DSN-Less ODBC Linked-tabel te maken staat hieronder. Als Access nieuw voor u is en VBA nieuw voor u, is dit waarschijnlijk niet zo logisch voor u. De code verwijdert elke tabeldefinitie die al bestaat voor de tabel die u probeert te koppelen, wat een beetje gevaarlijk is omdat ik denk dat het een lokale, niet-gekoppelde tabel zou kunnen verwijderen die u niet zou willen. De foutafhandeling hier is ook niet echt op snelheid, maar de meeste online voorbeeldcode heeft geen goede foutafhandeling vanwege de complicaties die ermee gepaard gaan. Het maken van primaire sleutelindexen op een gekoppelde tabel is niet altijd nodig. Ik heb het gewoon in mijn functie ingebouwd omdat ik het een keer nodig had voor een specifiek project, dus nu laat ik het erin en gebruik ik het, ten goede of ten kwade.

Om deze code goed te gebruiken, moet je echt ergens een lijst van al je gekoppelde tabellen hebben en die lijst doorlopen en deze functie voor elke tabel aanroepen. Met deze functie kunt u de tabel koppelen met een andere naam dan de werkelijke naam in SQL Server. U moet ook een manier hebben om een geldige ODBC-verbindingsreeks te bouwen die ook aan deze functie moet worden doorgegeven.

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

Er zijn een paar echt goede bronnen die u moet bekijken met betrekking tot DAO, ADO, Pass Through Queries, SQL Server, enz.:

http://technet.microsoft.com /nl-nl/bibliotheek/bb188204%28v=sql.90%29.aspx
http://www.utteraccess.com/wiki/Choosing_between_DAO_and_ADO

Hier is een voorbeeld van het binden van een formulier aan een ADO-recordset. Het is echter een beetje misleidend omdat het het beste is om een globaal verbindingsobject te hebben dat open blijft tijdens de runtime van de applicatie. Hierdoor kunt u ADO-recordsets gebruiken die automatisch kunnen worden bijgewerkt. Door deze oefening te gebruiken, kan uw recordset ook een object op formulierniveau worden.

http://msdn.microsoft .com/en-us/library/office/bb243828%28v=office.12%29.aspx