Microsoft Access VBA pour modifier les requêtes SQL

Question

J'ai une base de données Access avec une seule requête. Je peux actuellement copier la requête via VBA, en utilisant DoCmd.CopyObject. Cependant, j'ai besoin de pouvoir éditer le SQL dans chaque instance de la requête individuellement. Tous les exemples que j'ai vus cependant, impliquent un jeu d'enregistrements, ce que je n'utilise pas.

Des idées?

Avec grâce,

Est-ce

Answer 1

La question est un peu mince sur ce type de requête que vous souhaitez modifier, mais que c'est une requête de sélection qui n'a pas besoin de paramètres dynamiques. Puis, en utilisant la méthode CopyObject, copiez la requête comme vous l'avez fait. Utilisez l'objet Catalogue (vous devrez faire référence à l'extension ADO). Ensuite, vous pouvez simplement modifier le SQL de la copie comme ci-dessous. Selon votre requête, il peut s'agir d'une vue ou d'une procédure, mais une requête de sélection doit être répertoriée en tant que vue.

Espérons que cela aide.

Siva

Dim catDB As ADOX.Catalog 
Dim cmd As ADODB.Command 
Dim sQueryName As String 
Dim sSQL As String 

Set cn = CurrentProject.Connection 
Set catDB = New ADOX.Catalog 

catDB.ActiveConnection = cn 
DoCmd.CopyObject , "Query1_c", acQuery, "Query1" 
sQueryName = "Query1_c" 
sSQL = "SELECT a,b,c FROM Table1" 

Set cmd = New ADODB.Command 
Set cmd = catDB.Views(sQueryName).Command 
cmd.CommandText = sSQL 
Set catDB.Views(sQueryName).Command = cmd 

Set catDB = Nothing 
cn.Close 

Answer 2

que je fais ce genre de chose tout le temps! J'ai utilisé VBA pour réécrire les requêtes Access ainsi que les requêtes qui "passent" à une base de données MySQL. La réécriture d'une requête dans VBA dépend de la complexité que vous souhaitez obtenir.

J'ai toujours utilisé DAO, qui est plus ancienne technologie (voir les commentaires ci-dessous pour clarifcation sur DAO vs ADO), mais il a travaillé pour moi dans ce cas. Vous devrez ajouter une référence à DAO dans VBA en allant dans Outils> Références, puis ajoutez "Bibliothèque d'objets Microsoft DAO 3.6".

Vous pouvez écrire une procédure qui ressemble à ceci:

Sub RewriteQuerySQL(strQueryName As String, strParameter As String) 
    Dim db As DAO.Database 
    Dim qdf As DAO.QueryDef 
    Set db = CurrentDb() 
    Set qdf = db.QueryDefs(strQueryName) 

    qdf.SQL = "SELECT [Table].Field1, [Table].Field2 " & vbCrLf & _ 
      "FROM [Table] " & vbCrLf & _ 
      "WHERE ([Table].Field1 = " & chr(34) & strParameter & chr(34) & ");" 
End Sub 

Le code ci-dessus va changer SQL pour la requête que vous spécifiez avec la requête SQL dans le code VBA avec le strParameter intégré dans le SQL question.

Voici une autre façon de le faire. Ceci est du code que j'utilisé dans une application de déclaration des ventes de réécrire une requête basée sur un numéro de vendeur:

Sub rewriteAccountsBySalesRepSortSQL(lngSalesRep As Long) 
Dim db As DAO.Database 
Dim qdf As DAO.QueryDef 
Dim strSQL As String 
Dim strOriginal As String 
Dim strReplacePart As String 
Dim strSQLReplace As String 
Dim lngLocSalesperson As Long 
Dim lngLocMyRoundUp As Long 
Dim lngLocParen As Long 
Dim lngLocEndParen As Long 

Set db = CurrentDb() 
Set qdf = db.QueryDefs("qryS Accounts by Sales Rep Sorted by Diff DESC") 
strSQL = qdf.SQL 

lngLocSalesperson = InStr(strSQL, "Salesperson1)=") 
lngLocEndParen = InStr(lngLocSalesperson + 14, strSQL, ")") 
strOriginal = Mid(strSQL, lngLocSalesperson, lngLocEndParen - lngLocSalesperson) 
'lngLocParen = InStrRev(strSQL, "(", lngLocSalesperson) 

strReplacePart = "Salesperson1)=" & lngSalesRep 

strSQLReplace = Replace(strSQL, strOriginal, strReplacePart) 
qdf.SQL = strSQLReplace 




End Sub 

au lieu d'écrire toute requête, le code trouve simplement le numéro de représentant des ventes et le remplace par le nouveau nombre. En fait, je préfère la dernière méthode. La dernière méthode a été utilisée pour envoyer une requête directement à MySQL, donc la syntaxe avec une requête Access peut être légèrement différente.

Answer 3

Je ne suis pas d'accord avec toutes les réponses données ici, même si elles répondent à la question posée. Je suis en désaccord parce que je pense que la question est basée sur des hypothèses incorrectes - il n'est pas nécessaire de réécrire le SQL du tout.

La question semble supposer que les requêtes dans Access doivent être sauvegardées. Ils ne le font pas. Vous pouvez exécuter n'importe quelle chaîne SQL arbitraire à tout moment, soit dans le code, soit (pour le SQL non-DML) comme la source d'enregistrements d'un formulaire ou d'un rapport. Les chaînes SQL peuvent être créées à la volée et attribuées selon les besoins au moment de l'exécution. Le seul avantage d'un QueryDef enregistré est si vous devez l'utiliser dans plusieurs emplacements.

Un QueryDef enregistré est fondamentalement identique à un VIEW dans des bases de données de serveur.

Si QueryDef a des paramètres, cela équivaut à une simple PROCEDURE STOCKEE (c'est-à-dire, ceux qui manquent de code, comme IF/THEN ou CASE SELECT).

Si vous souhaitez implémenter le SQL en tant que VIEW sur une base de données de serveur, enregistrez-le en tant que QueryDef dans Access. Si vous le faites en tant que SPROC dans votre base de données de serveur, implémentez-le en tant que requête de paramètre enregistrée.

Mais tout d'abord, déterminez s'il doit être sauvegardé du tout.

Pour ce que ça vaut, j'ai programmé professionnellement dans Access depuis 1996 et je n'économise généralement pas beaucoup de requêtes, et en particulier ne pas enregistrer critères dans les requêtes. Les critères sont spécifiques au contexte d'exécution et doivent être fournis au moment de l'exécution plutôt que sauvegardés dans QueryDef. J'utilise QueryDefs sauvegardé pour le SQL complexe que j'ai besoin de réutiliser ou pour définir des "vues" (en particulier celles avec des jointures complexes) qui sont utilisées à plus d'un endroit dans l'application.

La question initiale n'identifie pas le contexte dans lequel le changement des critères est nécessaire, il est donc vraiment impossible de suggérer la meilleure approche. C'est un cas où je reprocherais à la question d'exclure une discussion appropriée car elle propose une SOLUTION spécifique et demande comment la mettre en œuvre, au lieu de décrire le PROBLÈME et de demander l'éventail des solutions réalisables. Pour ce faire, nous devons connaître le contexte (le SQL DML ou un SELECT? Est-il utilisé dans le code ou comme source de données pour un formulaire ou un rapport? Etc.), mais cela fait complètement défaut ici , donc une gamme complète de solutions ne sera jamais proposée.