[VBA ADO] Requête enregistrée qui change de collection

Version imprimable

Voir 40 message(s) de cette discussion en une page

11/05/2007, 17h57
NLozo

[VBA ADO] Requête enregistrée qui change de collection

Bonjour,

Je créé une requête enregistrée dans Access à l'aide de VBA. J'obtiens quelques fois le message suivant : Impossible de trouver l'objet dans la collection correspondant au nom ou à la référence ordinale demandé..

Après une trace de mon code, je vois que lorsque ce problème arrive, l'objet n'est plus dans la collection Views, mais dans la collection Procedures, alors que j'avais clairement fait :

Code:

cat.Views.Append nomRequete, cmd

Est-ce que le fait de ne pas déterminer le Provider lors de la connexion, mais d'utiliser CurrentProject.connection, pourrait être la source de mon problème ? Voici pourquoi je me pose la question (j'ai trouvé ça dans l'aide VBA Access) :

Citation:

Remarque En cas d'utilisation du fournisseur OLE DB pour Microsoft Jet, la méthode Append de la collection Views permet de spécifier un objet Procedure à la place d'un objet View dans le paramètre Command. L'objet Procedure est ajouté à la source de données, puis à la collection Views. Après Append, si les collections Procedures et Views sont actualisées, l'objet Procedure ne fait plus partie de la collection Views et apparaît dans la collection Procedures.

Est-ce que le fournisseur OLE DB est le fournisseur par défaut pour ADO ? Que dois-je prendre comme fournisseur ?

Un éclaircissement serait grandement apprécié. Merci à l'avance !

Nathalie

Oui c'est ta requête qui accroche

Regarde bien ce bout de requête que tu as fait

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
Private Sub EnregistrerRequete()
 
On Error GoTo err_EnregistrerRequete
 
    Dim cmdSQL As String
    Dim strNom As String
    Dim flgCond As Boolean
 
    strNom = "rTerr" & strUser
    flgCond = False
 
    cmdSQL = "SELECT * FROM Territoire"
 
    If Not flgAnnule Then
 
        'ajout de la ou des conditions
        cmdSQL = cmdSQL & " WHERE ("
 
        'Vérification des cases à cocher
        For Each ctl In Me.Controls
            strCtl = ctl.Properties("Name")
            If Left(strCtl, 3) = "chk" Then
                If ctl Then
                    strFld = Mid(strCtl, 4)
                    'S'il y a plus d'une condition...
                    If flgCond Then cmdSQL = cmdSQL & " OR "

il se peut que ça donne ceci comme résultat :
select * from Territoire
where ( OR
Refais cette partie et tiens moi au courant Nath ;)
Entre québécois il faut s'entraider ;)
Alex

11/05/2007, 21h54
NLozo

La requête fonctionne

Merci Alex, super que tu me répondes. Je ne m'attends pas tellement à une réponse de gentils amis français et françaises, parce qu'à cette heure un vendredi, ils sont tous attablés joyeusement autour d'une bonne bouffe et du bon vin entre amis... les chanceux ! ;)

Alors j'ai testé et la requête que ça donne peut ressembler à ça :

Code:

SELECT * FROM Territoire WHERE ((Territoire.No_Terr = 58) OR (Territoire.No_Terr = 67) OR (Territoire.No_Terr = 581) OR (Territoire.No_Terr = 671) OR (Territoire.No_Terr = 582) OR (Territoire.No_Terr = 672) OR (Territoire.No_Terr = 583) OR (Territoire.No_Terr = 584) OR (Territoire.No_Terr = 585) OR (Territoire.No_Terr = 59) OR (Territoire.No_Terr = 591)) ORDER BY Territoire.No_Terr

Je l'ai fait afficher dans un dialogue et j'avais déjà vérifié. J'ai un flag qui me permet de vérifier s'il y a déjà une condition pour le placer à la suite.

Il faut dire aussi que l'application fonctionne généralement très bien. C'est seulement qu'une fois de temps en temps, j'ai le message d'erreur mentionné plus haut et que la trace m'indique que la requête que j'ai enregistré et qui est normalement un objet View, devient tout d'un coup un objet Procedures sans crier gare. On fait OK sur l'erreur, on recommence et ça fonctionne. C'est juste un peu embêtant de distribuer l'application comme ça.

Merci encore, et au cas où, bonne fin de semaine !

Nath
17/05/2007, 17h44
NLozo

Peut-être ne suis-je pas assez concise !

Bonjour,

Comme je n'ai pas beaucoup de réponse :cry: , je me permets de reposer la question autrement en espérant être plus claire :

J'aimerais seulement savoir si, avec la librairie ADO, une requête enregistrée comportant une clause WHERE doit obligatoirement être une requête paramétrée (donc, si j'ai bien compris, dans la collection Procedures), ou peut demeurer une requête non paramétrée (si j'ai toujours bien compris, dans la collection Views) ?

Dans le contexte mentionné plus haut, comme je ne connais pas d'avance le nombre de paramètres, je vois difficilement comment créer une requête paramétrée. Quelqu'un pourrait me mettre sur la piste ? :marteau:

Merci à l'avance !

Nathalie
18/05/2007, 15h50
NLozo

Une question de Provider ?

Est-ce que mon problème pourrait venir du fait que je n'ai pas explicitement définit la connexion ?

Voici ce que j'ai trouvé dans l'aide Access et que j'aimerais bien qu'on me traduise dans un style «pour les nuls» :

Citation:

Remarque En cas d'utilisation du fournisseur OLE DB pour Microsoft Jet, la méthode Append de la collection Views permet de spécifier un objet Procedure à la place d'un objet View dans le paramètre Command. L'objet Procedure est ajouté à la source de données, puis à la collection Views. Après Append, si les collections Procedures et Views sont actualisées, l'objet Procedure ne fait plus partie de la collection Views et apparaît dans la collection Procedures.

Ce qui m'inquiète dans la définition de la connexion, c'est d'avoir à y inscrire un path physique pour le Data Source. Est-ce que ça peut être un path logique ? J'aurai à installer l'application sur 22 serveurs différents !!

J'ose espérer de vos nouvelles ! :cry:
18/05/2007, 18h50
alexandrebergercyr

Le view est plus difficile qu'un recordset

L'utilisation d'un view est plus difficile qu'un recordset, mais il fait l'affaire aussi ;). De plus, j'ai remarqué que tu veux avoir le path physique? Application.CurrentProject.Path ou tu veux s'avoir l'usager utilisant le programme Environ("username") ou si tu veux avoir le nom de ta bd Application.CurrentDb.Name...

Il y a des bon exemple de recorset sur le net et au besoin je peux t'en trouver un, mais je crois que tu es sûrement capable d'en trouver un par toi même il en as une tonne.

Alex Bonne fin de semaine
18/05/2007, 18h52
alexandrebergercyr

Voici un très bon site...

Il peut t'aider dans ta recherche pour le path physique d'un coup que j'aie pas mentionné celui que tu voulais : http://blogs.officezealot.com/charle...2/10/3574.aspx
Alex

Je précise

Est-ce que le fait d'utiliser :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
Function verifierRequete(nomRequete As String) As Boolean
 
On Error GoTo Err_verifierRequete
 
    Dim cat As New ADOX.Catalog
    Dim vue As view
 
    cat.ActiveConnection = CurrentProject.Connection
 
    verifierRequete = False
 
    For Each vue In cat.Views
        If vue.Name = nomRequete Then
            verifierRequete = True
            Exit For
        End If
    Next vue
 
Exit_verifierRequete:
    Set cat = Nothing
    Exit Function
 
Err_verifierRequete:
    MsgBox Err.Description
    Resume Exit_verifierRequete
 
End Function

...pour vérifier si la requête se trouve dans les vues est correct ?

25/05/2007, 15h03
NLozo

Merci pour les pistes, Alex, pour le path !:)

Par ailleurs, j'aimerais savoir si je peux utiliser un autre Provider qu'OLEDB pour une connexion ADO afin de ne plus rencontrer de problème de changement de collection de mon objet View (voir Remarques, citation plus haut trouvée dans l'aide VBA Access). Ou peut-être n'est-ce pas recommandé de changer ?

Merci !

Nath
25/05/2007, 15h13
alexandrebergercyr

Nope ceci n'est pas correct

cat.Views retourne un élément de moins que réellement :S
Il faudrait prendre une autre façon de vérifier si ta requête existe.
Alex

Problème de cette référence.
ActiveX Data Objects Extensions
25/05/2007, 15h14
alexandrebergercyr

Tu es rapide...

Ok je cherche un peu de mon côté une autre façon de faire sur la faq ou sur google et je te reviens dessus.

Alex

Et bien moi aussi

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
Public Function TesteExistenceRequete(strNomRequete As String) As Boolean
On Error GoTo err
Dim Db As DAO.Database
Dim QryTest As DAO.QueryDef
'initialise un objet représentant la base de données
Set Db = CurrentDb
'tente d'accéder à la requête
Set QryTest = Db.QueryDefs(strNomRequete)
TesteExistenceRequete = True
err:
End Function

Ceci marche à merveille
Alex

P.S. N'oublie pas la référence Microsoft DAO (la plus récente)

25/05/2007, 15h37
NLozo

Un hic !

Merci Alex !

Le hic, c'est que je ne veux pas utiliser DAO. J'aimerais que mon application soit «transportable» et puisse évoluer. Je veux éventuellement développer SQL-Server. J'ai cru comprendre qu'un accès ADO le permettait. Est-ce que j'ai bien compris ?

Nath
25/05/2007, 15h48
alexandrebergercyr

Ehh j'ai de la misère à comprendre

Salut Nath, comment ça va en ce beau Vendredi ensolleilé entre 4 mur?
Bon revenons à nos moutons c'est Alexandre Berger qui te le dis.

La première façon de faire pour vérifier si la requête existait avec besoin de la référence ADO, car elle ne marche pas sans. (en plus, elle marchait mal.)

La façon que je t'ai proposé fait référence à DAO et elle marche mieux.

Donc, je ne vois pas comment le faire sans référence, car c'est vraiment la référence qui permet d'accéder à nos objets...

Alexxx
25/05/2007, 15h59
NLozo

Hum !

J'ai bien référencé ma bibliothèque «Microsoft ADO Ext. 2.7 for DDL and Security». Et comme je t'ai dit, ça fonctionne très bien 98 % du temps. C'est le 2 % du temps qui me déplaît et qui me retient de l'installer aux utilisateurs !

Je vous jure, ADO, quel casse-tête !!! J'en viens à regretter de l'avoir utilisé. Mais que voulez-vous, je suis têtue de nature... et un peu masochiste sur les bords !! :marteau: :sm: :mouarf:

Nath
25/05/2007, 16h12
alexandrebergercyr

Bref, je te dis le problème

Bref, je te dis le problème...

Avec la fonction que tu as codé en ADO, il ne voit pas la première requête.

Je ne sais pas quoi dire d'autre.

Bonne chance.
Alex
:lahola:
:pingoin2:
25/05/2007, 16h27
NLozo

Et pourquoi il ne voit pas la première requête... je pense que j'ai besoin d'un dessin, là... ! :roll:

Nath
25/05/2007, 16h36
alexandrebergercyr

1 pièce(s) jointe(s)

Voilà ton dessin

Voici un exemple de bd ... la requête qui s'appelle patate ne sera pas dans ton for each.

Ce qui serait une solution (mais elle est pas idéal), c'est de te créer une requête intitulé 000000000 (elle sera en premier de toute).

C'est vraiment pas élégant, mais c'est une solution étant donné que tu veux absolument pas utiliser la référence DAO qui marche à merveille.

Alexxx
:sm:
25/05/2007, 17h17
NLozo

Continue, j'aime ça... Hihihi

:mouarf:
Alors si je comprends bien, ce n'était pas une bonne idée d'utiliser ADO, pour ensuite sauvegarder des requêtes (du nom des utilisateurs) dans ma base Access (requêtes que je détruis en quittant l'appl). Si je veux être plus soft, je devrais utiliser des recordsets, c'est ça ? C'est que je voulais que les jeux d'enregistrements perdurent et puissent être récupérés tant que l'application est ouverte... j'imagine comme les procédures stockées dans SQL-Server...

Nath
25/05/2007, 17h34
alexandrebergercyr

Pkoi tu utilise pas les deux références!

Re-salut Nath, ceci est mon dernier courriel avant la fin de semaine...

Donc, oui ça serait plus facile avec les recordset.
Du moins je crois...
Il n'y a pas de bonne, ni de mauvaise façon de faire.
Juste des façons de faire plus compliqué.
Je t'ai proposé beaucoup de solutions comme tu viens de la mentionné.
Donc, je suis sûre que tu es capable de te débrouillé.

J'ai déjà lu sur une autre faq ce message :
"Si tu donne un poisson à un homme il sera rassasié pour la journée.
Si tu donne une canne-à-pêche il le sera pour l'éternité."

Alexxx qui te souhaite bonne fin de semaine tout en te fouettant.
:sm:

Voir 40 message(s) de cette discussion en une page