Comment faire un passthrough / passthru requête modifiable?

En ligne avec mon commentaire ci-dessus et la réponse par Yawar, je ne suis pas au courant qui Passe à Travers les Requêtes sont toujours modifiables/jour. Ils sont modifiables dans le sens que vous pouvez modifier un enregistrement de Passage Par la Requête de l'objet, mais je ne crois pas qu'il est possible pour un Passage Par la Requête pour produire un jeu d'enregistrements modifiable.

Il existe essentiellement deux méthodes pour se connecter à l'Accès à un non-Accès aux sources de données.

La première méthode, et la plus populaire, est d'utiliser une certaine forme de tables liées, en général ODBC tables liées. Il existe une variété de méthodes d'utilisation des tables ODBC liée avec MS Access, mais par ce que la plupart des développeurs préfèrent consiste à utiliser des connexions sans DSN que vous rafraîchir ou reconstruit (supprimé et rebranché) au moment de votre application démarre. Soyez conscient que lorsque vous utilisez ODBC, vous êtes également toujours à l'aide de DAO. DAO est l'accès aux données par défaut de l'objet construit dans MS Access et même lorsque vous n'avez pas spécifiquement écrire n'importe quel code DAO, MS Access est toujours à l'aide de DAO sous le capot pour lier vos formulaires, des rapports et des requêtes à votre source de données. Dans le cas d'ODBC, vous avez en fait avoir deux couches d'accès aux données au travail, DAO et ODBC. Mais vous pouvez utiliser ODBC/DAO avec de jolies performances décentes et sans écrire de code (autres que de maintenir les tables ODBC liée).

La deuxième méthode consiste à utiliser ADO. Contrairement à la croyance populaire, cela ne signifie pas que vous avez à utiliser des formulaires indépendants. Mais ça ne signifie pas que vous avez à écrire plus de code que l'utilisation de JET/DAO/MSAccess ou DAO/ODBC/SSQL Serveur. Vous devez écrire le code pour afficher dans les enregistrements de votre base de données dans et jeu d'enregistrements ADO et utiliser le code pour lier votre forme à un jeu d'enregistrements. Vous devez écrire plus de code pour garder enfant de formes en synchronisation avec les formulaires parent, d'insérer les clés étrangères dans les formulaires enfants lorsque de nouveaux dossiers sont créés, et pour une variété d'autres choses, comme le filtrage et le tri sélectif et la forme intégrée de filtrage et de tri des options habituellement ne fonctionnent pas avec les jeux d'enregistrements ADO. ADO est un excellent moyen de parler à SQL Server car il vous donne beaucoup de contrôle, mais parce que c'est le code intense, et parce que les Tables ODBC Liée fonctionne si bien, la plupart des développeurs ne recommandons pas l'utilisation d'ADO à moins qu'il n'y a pas d'autre moyen de faire ce que vous voulez faire. Un exemple de ceci est l'appel de Procédures Stockées. Je pense Passer à Travers les Requêtes peuvent être utilisés pour appeler des Procédures Stockées, mais je pense aussi qu'il y a certaines limites y (tels que l'utilisation de Paramètres). Je crois que dans la plupart des cas, les développeurs à utiliser ADO pour appeler des procédures stockées. J'utilise ADO beaucoup, mais je ne suis pas d'utiliser des Procédures Stockées beaucoup (pas encore) donc je n'ai pas beaucoup d'informations.

Une autre chose à mentionner est que les DAO avec ODBC utilise "lazy loading" mais ADO vous oblige à tirer toutes les données qui peuvent être très coûteuse en temps et de consommer beaucoup de mémoire si vous avez > des millions de lignes. Ou d'autre, vous aurez besoin de mettre en œuvre une sorte de pagination.

Ma propre fonction pour créer un seul DSN ODBC Liée tableau ci-dessous. Si vous êtes nouveau à l'Accès et à nouveau à VBA ce ne sera probablement pas faire beaucoup de sens pour vous. Le code supprime toute définition de la table qui existe déjà pour la table que vous essayez de lien, qui est un peu dangereux parce que je crois qu'il pourrait supprimer un local, non lié à la table dont vous ne voulez pas. La gestion d'erreur dans ici n'est pas vraiment à la vitesse, mais la plupart des en ligne exemple de code n'a pas une bonne gestion des erreurs en raison de complications que cela implique. La création de la Clé Primaire Index sur une table liée n'est pas toujours nécessaire. Je viens de l'avoir intégré dans ma fonction, parce que j'en ai eu besoin une seule fois pour un projet spécifique, donc maintenant je le laisser là et de l'utiliser, pour le meilleur ou pour le pire.

À faire bon usage de ce code, vous avez vraiment besoin d'avoir une liste de tous vos tables liées quelque part et parcourir cette liste et appeler cette fonction pour chaque table. Cette fonction permet de lier la table à l'aide d'un autre nom que son nom réel dans SQL Server. Vous avez également besoin d'avoir un moyen de la construction d'un valide chaîne de connexion ODBC qui doit être passé dans cette fonction trop.

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

Il y a quelques vraiment bonnes ressources, vous devriez vérifier concernant DAO, ADO, Passer Par le biais de Requêtes SQL Server, etc:

http://technet.microsoft.com/en-us/library/bb188204%28v=sql.90%29.aspx

http://www.utteraccess.com/wiki/Choosing_between_DAO_and_ADO

Voici un exemple de liaison d'un formulaire à un jeu d'enregistrements ADO. C'est un peu trompeur, car il est préférable d'avoir un objet de connexion global qui reste ouverte lors de l'exécution de l'application. Cela vous permet d'utiliser des jeux d'enregistrements ADO qui sont automatiquement mis à jour. À l'aide de cette pratique peut également rendre votre jeu d'enregistrements à un niveau de forme de l'objet.

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

Passer les requêtes des ensembles de résultats ne sont pas modifiables, mais l'Accès des requêtes basées sur des tables liées sont certainement.