Conformément à mon commentaire ci-dessus et à la réponse de Yawar, je ne sais pas si les requêtes directes sont modifiables/mis à jour. Ils sont modifiables dans le sens où vous pouvez modifier un objet de requête directe de sauvegarde, mais je ne crois pas qu'il soit possible qu'une requête directe produise un jeu d'enregistrements modifiable.
Il existe essentiellement deux méthodes pour connecter Access à une source de données non-Access.
La première méthode, et la plus populaire, consiste à utiliser une certaine forme de tables liées, généralement des tables liées ODBC. Il existe diverses méthodes d'utilisation des tables liées ODBC avec MS Access, mais la plupart des développeurs préfèrent utiliser des connexions sans DSN qui sont actualisées ou reconstruites (supprimées et reconnectées) au démarrage de votre application. Sachez que lorsque vous utilisez ODBC, vous utilisez toujours DAO. DAO est l'objet d'accès aux données par défaut intégré à MS Access et même lorsque vous n'écrivez pas spécifiquement de code DAO, MS Access utilise toujours DAO sous le capot pour lier vos formulaires, rapports et requêtes à votre source de données. Dans le cas d'ODBC, vous finissez par avoir deux couches d'accès aux données au travail, DAO et ODBC. Mais vous pouvez utiliser ODBC/DAO avec des performances assez décentes et sans écrire de code (autre que pour maintenir les tables liées ODBC).
La deuxième méthode consiste à utiliser ADO. Contrairement à la croyance populaire, cela ne signifie pas que vous devez utiliser des formulaires non liés. Mais cela signifie que vous devez écrire plus de code que d'utiliser JET/DAO/MSAccess ou DAO/ODBC/SSQL Server. Vous devez écrire du code pour importer des enregistrements de votre base de données dans un jeu d'enregistrements ADO, puis utiliser du code pour lier votre formulaire à ce jeu d'enregistrements. Vous devez écrire plus de code pour garder les formulaires enfants synchronisés avec les formulaires parents, pour insérer des clés étrangères dans les formulaires enfants lorsque de nouveaux enregistrements sont créés, et pour une variété d'autres choses aussi comme le filtrage et le tri en tant que filtrage et tri intégrés du formulaire. les options ne fonctionnent généralement pas avec les jeux d'enregistrements ADO. ADO est un excellent moyen de parler à SQL Server car il vous donne vraiment beaucoup de contrôle, mais parce que le code est intense et parce que les tables liées ODBC fonctionnent si bien, la plupart des développeurs ne recommandent pas d'utiliser ADO à moins qu'il n'y ait pas d'autre moyen de faire quoi vous voulez faire. Un exemple de ceci est l'appel de procédures stockées. Je pense que les requêtes directes peuvent être utilisées pour appeler des procédures stockées, mais je pense également qu'il existe certaines limitations (telles que l'utilisation de paramètres). Je crois que dans la plupart des cas, les développeurs utilisent ADO pour appeler des procédures stockées. J'utilise beaucoup ADO mais je n'utilise pas beaucoup les procédures stockées (pas encore) donc je n'ai pas beaucoup d'informations à ce sujet.
Une autre chose à mentionner est que DAO avec ODBC utilise le "chargement différé", mais ADO vous oblige à extraire toutes les données, ce qui peut prendre beaucoup de temps et consommer beaucoup de mémoire si vous avez> des millions de lignes. Sinon, vous devrez implémenter une sorte de pagination.
Ma propre fonction pour créer une seule table liée ODBC sans DSN est ci-dessous. Si vous êtes nouveau sur Access et nouveau sur VBA, cela n'aura probablement pas beaucoup de sens pour vous. Le code supprime toute définition de table qui existe déjà pour la table que vous essayez de lier, ce qui est un peu dangereux car je pense qu'il pourrait supprimer une table locale non liée dont vous ne voudriez pas. La gestion des erreurs ici n'est pas vraiment à jour non plus, mais la plupart des exemples de code en ligne n'ont pas une bonne gestion des erreurs en raison des complications que cela implique. La création d'index de clé primaire sur une table liée n'est pas toujours nécessaire. Je l'ai juste intégré à ma fonction parce que j'en avais besoin une fois pour un projet spécifique, alors maintenant je le laisse là et je l'utilise, pour le meilleur ou pour le pire.
Pour utiliser correctement ce code, vous devez vraiment avoir une liste de toutes vos tables liées quelque part et parcourir cette liste et appeler cette fonction pour chaque table. Cette fonction vous permet de lier la table en utilisant un nom différent de son nom réel dans SQL Server. Vous devez également disposer d'un moyen de créer une chaîne de connexion ODBC valide qui doit également être transmise à cette fonction.
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 existe quelques très bonnes ressources que vous devriez consulter concernant DAO, ADO, Pass Through Queries, 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 ouvert pendant l'exécution de l'application. Cela vous permet d'utiliser des jeux d'enregistrements ADO qui peuvent être automatiquement mis à jour. L'utilisation de cette pratique peut également faire de votre jeu d'enregistrements un objet au niveau du formulaire.
http://msdn.microsoft .com/en-us/library/office/bb243828%28v=office.12%29.aspx
