Versions Access : Index, Seek ...

Le
Gloops
Bonjour tout le monde,

Après m'être heurté un certain nombre de fois à l'erreur 3251 (op=
ération
non autorisée pour ce type d'objet) en appliquant sous Access 2000 les =

syntaxes auxquelles j'étais habitué sous Access 95 et 97, j'essaie de=

trouver, quelque part, une synthèse sur les types de jeux
d'enregistrements qui acceptent la propriété Index et la syntaxe Seek=

qui va avec : Rs.Seek "=", Clé1, Clé2

Il serait intéressant entre autres de savoir sur quoi on peut les ouvri=
r
(une table, une requête, ordonnée ou non, )

Dans la doc il m'a semblé voir que dbOpenDynaset faisait l'affaire pour=

désigner un index pour le jeu d'enregistrements, mais dans la pratique =

je ne suis pas certain qu'il n'y ait pas certaines restrictions.

Par ailleurs sous Access 2000 j'utilise systématiquement la déclarati=
on
tardive, du style

Dim Rs As Object ' Recordset
Dim DB As Object ' Database

Je ne suis pas le premier à trouver qu'un gestionnaire de bases de
données qui ne connaît pas l'objet Database sans qu'on aille lui
chercher un dictionnaire au coup par coup (en précisant les référen=
ces),
ça représente une certaine gymnastique de l'esprit. Je ne sais pa=
s
si tout le monde retombe sur le tapis dans ce genre d'exercice,
peut-être quelqu'un voit-il un éclaircissement à apporter.

Pour utiliser l'autre syntaxe de Seek (Rs.Seek Array(clefs),
adSeekAfterEQ), dans les cas où les champs varient d'un appel à l'aut=
re,
j'ai bricolé une fonction qui va chercher les champs dans un index pour=

les comparer un à un. Dans la première utilisation que j'en ai faite,=

sur une table, ça marche bien, après quand il s'est agi d'utiliser ç=
a
sur une requête avec sélection, je me suis fait jeter. Je risque donc=

d'avoir à passer un autre argument qui fournisse les champs à utilise=
r,
à moins que quelqu'un voie une idée lumineuse pour l'éviter, dans l=
'idée
que si on a moins d'arguments à passer pour faire la même chose, ça=

risque d'être plus commode à appeler (à écrire, bien entendu, c'e=
st une
autre affaire).

Voilà, si quelqu'un me voit aller droit dans le fossé, il peut le dir=
e
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Raymond [mvp]
Le #6297201
Bonsoir.

on va limiter les possibilités.

avant de faire seek il faut charger l'index :
Rs.Index = "PrimaryKey"
Rs.Seek "=", Clé1, Clé2
faire suivre de NoMatch pour tester si trouvé
ok pour ça ?

seek ne fonctionne que sur sur des recordset de type table. encore bon ?

seek est interdit sur les tables attachées. aïe, aïe, aïe !
utiliser FindFirst uniquement

où en es-tu maintenant ?

--
@+
Raymond Access MVP http://www.OfficeSystemAccess.com/
http://officesystem.access.over-blog.com/
http://officesystem.access.free.fr/wiki/
Pour débuter sur le forum: http://www.mpfa.info/

Venez découvrir Open XML, le nouveau format de fichier de la suite Office !
http://www.comscamp.com/Tracker/Redirect.ashx?linkidÿ71c7f3-78e8-4371-abaf-b73c259e58db


"Gloops"
Bonjour tout le monde,

Après m'être heurté un certain nombre de fois à l'erreur 3251 (opération
non autorisée pour ce type d'objet) en appliquant sous Access 2000 les
syntaxes auxquelles j'étais habitué sous Access 95 et 97, j'essaie de
trouver, quelque part, une synthèse sur les types de jeux
d'enregistrements qui acceptent la propriété Index et la syntaxe Seek
qui va avec : Rs.Seek "=", Clé1, Clé2

Il serait intéressant entre autres de savoir sur quoi on peut les ouvrir
(une table, une requête, ordonnée ou non, ...)

Dans la doc il m'a semblé voir que dbOpenDynaset faisait l'affaire pour
désigner un index pour le jeu d'enregistrements, mais dans la pratique
je ne suis pas certain qu'il n'y ait pas certaines restrictions.

Par ailleurs sous Access 2000 j'utilise systématiquement la déclaration
tardive, du style

Dim Rs As Object ' Recordset
Dim DB As Object ' Database

Je ne suis pas le premier à trouver qu'un gestionnaire de bases de
données qui ne connaît pas l'objet Database sans qu'on aille lui
chercher un dictionnaire au coup par coup (en précisant les références),
ça représente ... une certaine gymnastique de l'esprit. Je ne sais pas
si tout le monde retombe sur le tapis dans ce genre d'exercice,
peut-être quelqu'un voit-il un éclaircissement à apporter.

Pour utiliser l'autre syntaxe de Seek (Rs.Seek Array(clefs),
adSeekAfterEQ), dans les cas où les champs varient d'un appel à l'autre,
j'ai bricolé une fonction qui va chercher les champs dans un index pour
les comparer un à un. Dans la première utilisation que j'en ai faite,
sur une table, ça marche bien, après quand il s'est agi d'utiliser ça
sur une requête avec sélection, je me suis fait jeter. Je risque donc
d'avoir à passer un autre argument qui fournisse les champs à utiliser,
à moins que quelqu'un voie une idée lumineuse pour l'éviter, dans l'idée
que si on a moins d'arguments à passer pour faire la même chose, ça
risque d'être plus commode à appeler (à écrire, bien entendu, c'est une
autre affaire).

Voilà, si quelqu'un me voit aller droit dans le fossé, il peut le dire ...
Gloops
Le #6296581
Raymond [mvp] a écrit, le 28/06/2007 20:45 :
seek ne fonctionne que sur sur des recordset de type table. encore bon ?

seek est interdit sur les tables attachées. aïe, aïe, aïe !
utiliser FindFirst uniquement

où en es-tu maintenant ?



Eh bien voilà où j'en suis : je ne réussis à utiliser Seek "=" QUE sur
des tables attachées (ou alors, j'aurais confondu quelque part ?).

Voilà ce que j'ai noté : une procédure avec Seek "=" fonctionnait , sur
une table attachée, et puis le client s'est mis dans la tête qu'il ne
voulait pas de table attachée (bon, après tout, c'est lui qui paie .. .),
et depuis que j'ai importé la table au lieu de l'attacher, Seek "=" m e
retourne une erreur.


Sur d'autres jeux d'enregistrements, j'ai pu utiliser Seek Array,
SeekAfterEQ, et encore pas à tous les coups.

Sur une synchronisation de deux tables, j'ai fini par en arriver à
parcourir, pour chaque enregistrement de la table source, tous les
enregistrements de la table cible en séquentiel, jusqu'à égalité. Et
quand je dis égalité, ça veut dire qu'à chaque enregistrement, je
parcours les huit champs clefs pour les comparer paire par paire, en
renseignant un booléen au passage. C'est besogneux, mais au moins ça ne
plante pas en route.

Moui, j'ai l'impression d'avoir encore de quoi apprendre, là-dessus.

Par tâtonnements j'arriverai bien à noter que dans tel cas ça march e,
dans tel autre non. Si il y avait plus rapide comme méthode
d'apprentissage (aussi), je ne dirais pas non ...

Raymond [mvp]
Le #6296551
Bonsoir.

je viens de relire les aides et j'ai trouvé ça:

pour ado:
Vous ne pouvez employer cette méthode que dans le seul cas où l'objet
Recordset a été ouvert avec une valeur adCmdTableDirect pour CommandTypeEnum

pour dao:
Vous ne pouvez pas utiliser la méthode Seek dans une table attachée car vous
ne pouvez pas ouvrir des tables attachées sous forme d'objets Recordset de
type table. Cependant, si vous utilisez la méthode OpenDatabase pour ouvrir
directement une base de données ISAM installable (non ODBC), vous pouvez
utiliser la méthode Seek dans les tables de cette base de données.

--
@+
Raymond Access MVP http://www.OfficeSystemAccess.com/
http://officesystem.access.over-blog.com/
http://officesystem.access.free.fr/wiki/
Pour débuter sur le forum: http://www.mpfa.info/

Venez découvrir Open XML, le nouveau format de fichier de la suite Office !
http://www.comscamp.com/Tracker/Redirect.ashx?linkidÿ71c7f3-78e8-4371-abaf-b73c259e58db


"Gloops" %
Raymond [mvp] a écrit, le 28/06/2007 20:45 :
seek ne fonctionne que sur sur des recordset de type table. encore bon ?

seek est interdit sur les tables attachées. aïe, aïe, aïe !
utiliser FindFirst uniquement

où en es-tu maintenant ?



Eh bien voilà où j'en suis : je ne réussis à utiliser Seek "=" QUE sur
des tables attachées (ou alors, j'aurais confondu quelque part ?).

Voilà ce que j'ai noté : une procédure avec Seek "=" fonctionnait, sur
une table attachée, et puis le client s'est mis dans la tête qu'il ne
voulait pas de table attachée (bon, après tout, c'est lui qui paie ...),
et depuis que j'ai importé la table au lieu de l'attacher, Seek "=" me
retourne une erreur.


Sur d'autres jeux d'enregistrements, j'ai pu utiliser Seek Array,
SeekAfterEQ, et encore pas à tous les coups.

Sur une synchronisation de deux tables, j'ai fini par en arriver à
parcourir, pour chaque enregistrement de la table source, tous les
enregistrements de la table cible en séquentiel, jusqu'à égalité. Et
quand je dis égalité, ça veut dire qu'à chaque enregistrement, je
parcours les huit champs clefs pour les comparer paire par paire, en
renseignant un booléen au passage. C'est besogneux, mais au moins ça ne
plante pas en route.

Moui, j'ai l'impression d'avoir encore de quoi apprendre, là-dessus.

Par tâtonnements j'arriverai bien à noter que dans tel cas ça marche,
dans tel autre non. Si il y avait plus rapide comme méthode
d'apprentissage (aussi), je ne dirais pas non ...

Gloops
Le #6296471
Bonjour,

En fait, c'est vrai que dans ma procédure j'ai ouvert la table externe,
après avoir ouvert sa base en lisant son chemin dans la propriété
Connect de la table liée (j'ai pourtant ouvert la base hier soir pour
regarder, mais il devait être temps d'arrêter ...)

En paramètre de OpenRecordset, sur la base externe, je passe juste le
nom de la table, donc j'imagine que par défaut sous Access 95 ça donn e
dbOpenTable (ça doit correspondre à acCmdTableDirect si on utilise Do Cmd).

Pour l'autre syntaxe Seek (Seek Array), les essais montrent que les
conditions ne sont pas les mêmes.

Je savais déjà qu'il y avait à distinguer ADO de DAO, à ce que je
comprends il faut aussi distinguer si la base est ODBC ou non, j'avoue
que là-dessus je vais devoir faire des révisions, avant les essais .. .

Si j'ai bien retenu quelque chose, Seek "=", Cle1, Cle2 est la syntaxe
DAO, tandis que Seek Array, adSeekAfterEQ convient à ADO.

L'aide contextuelle dépend de l'ordre des références appelées, pe ut-être ?
____________________________________________
Raymond [mvp] a écrit, le 29/06/2007 22:54 :
Bonsoir.

je viens de relire les aides et j'ai trouvé ça:

pour ado:
Vous ne pouvez employer cette méthode que dans le seul cas où l'obj et
Recordset a été ouvert avec une valeur adCmdTableDirect pour Comman dTypeEnum

pour dao:
Vous ne pouvez pas utiliser la méthode Seek dans une table attachée car vous
ne pouvez pas ouvrir des tables attachées sous forme d'objets Records et de
type table. Cependant, si vous utilisez la méthode OpenDatabase pour ouvrir
directement une base de données ISAM installable (non ODBC), vous pou vez
utiliser la méthode Seek dans les tables de cette base de données.



Raymond [mvp]
Le #6296461
Bonjour.

quelle que soit la méthode, ado ou dao, on n'utilise que très peu le seek en
lui préférant le findfirst avec une clause where "compliquée" et apparemment
le finfirst est nettement plus rapide que le seek. Comme, personnellement,
je ne me rappelle jamais si on peut ou on ne peut pas, je ne l'utilise pas
et je prends le findfirst.

--
@+
Raymond Access MVP http://www.OfficeSystemAccess.com/
http://officesystem.access.over-blog.com/
http://officesystem.access.free.fr/wiki/
Pour débuter sur le forum: http://www.mpfa.info/

Venez découvrir Open XML, le nouveau format de fichier de la suite Office !
http://www.comscamp.com/Tracker/Redirect.ashx?linkidÿ71c7f3-78e8-4371-abaf-b73c259e58db


"Gloops"
Bonjour,

En fait, c'est vrai que dans ma procédure j'ai ouvert la table externe,
après avoir ouvert sa base en lisant son chemin dans la propriété
Connect de la table liée (j'ai pourtant ouvert la base hier soir pour
regarder, mais il devait être temps d'arrêter ...)

En paramètre de OpenRecordset, sur la base externe, je passe juste le
nom de la table, donc j'imagine que par défaut sous Access 95 ça donne
dbOpenTable (ça doit correspondre à acCmdTableDirect si on utilise DoCmd).

Pour l'autre syntaxe Seek (Seek Array), les essais montrent que les
conditions ne sont pas les mêmes.

Je savais déjà qu'il y avait à distinguer ADO de DAO, à ce que je
comprends il faut aussi distinguer si la base est ODBC ou non, j'avoue
que là-dessus je vais devoir faire des révisions, avant les essais ...

Si j'ai bien retenu quelque chose, Seek "=", Cle1, Cle2 est la syntaxe
DAO, tandis que Seek Array, adSeekAfterEQ convient à ADO.

L'aide contextuelle dépend de l'ordre des références appelées, peut-être ?
Gloops
Le #6296421
Raymond [mvp] a écrit, le 30/06/2007 10:18 :
Bonjour.

quelle que soit la méthode, ado ou dao, on n'utilise que très peu l e seek en
lui préférant le findfirst avec une clause where "compliquée" et apparemment
le finfirst est nettement plus rapide que le seek. Comme, personnelleme nt,
je ne me rappelle jamais si on peut ou on ne peut pas, je ne l'utilise pas
et je prends le findfirst.



Ah bon, en plus d'être plus astreignant, le Seek est moins performant ?
Je me figurais qu'il avait au moins une qualité ...

Bon je vais plus faire joujou avec FindFirst et FindNext, alors.

Mais ... tu es sûr, de ça ?

http://support.microsoft.com/?scid=kb%3Ben-us%3B108149&x&y

Raymond [mvp]
Le #6296391
Il faut bien s'entendre sur le mot performance. l'article ne traite que des
tables locales, d'une part, et ne parle pas des déplacements ultérieurs dans
la table. En tables locales, ok, mais dans une application normale, il n'y a
pas de tables locales et je me vois mal faire un opendatabase à chaque seek
éventuel pour aller récupérer un objet table. l'utilisation du seek est très
très limitée et pour moi, on ne peut pas parler de performances avec un tel
outil.

--
@+
Raymond Access MVP http://www.OfficeSystemAccess.com/
http://officesystem.access.over-blog.com/
http://officesystem.access.free.fr/wiki/
Pour débuter sur le forum: http://www.mpfa.info/

Venez découvrir Open XML, le nouveau format de fichier de la suite Office !
http://www.comscamp.com/Tracker/Redirect.ashx?linkidÿ71c7f3-78e8-4371-abaf-b73c259e58db


"Gloops"
Raymond [mvp] a écrit, le 30/06/2007 10:18 :
Bonjour.

quelle que soit la méthode, ado ou dao, on n'utilise que très peu le seek
en
lui préférant le findfirst avec une clause where "compliquée" et
apparemment
le finfirst est nettement plus rapide que le seek. Comme, personnellement,
je ne me rappelle jamais si on peut ou on ne peut pas, je ne l'utilise pas
et je prends le findfirst.



Ah bon, en plus d'être plus astreignant, le Seek est moins performant ?
Je me figurais qu'il avait au moins une qualité ...

Bon je vais plus faire joujou avec FindFirst et FindNext, alors.

Mais ... tu es sûr, de ça ?

http://support.microsoft.com/?scid=kb%3Ben-us%3B108149&x&y

Gloops
Le #6296131
Raymond [mvp] a écrit, le 30/06/2007 14:20 :
Il faut bien s'entendre sur le mot performance. l'article ne traite que des
tables locales, d'une part, et ne parle pas des déplacements ultéri eurs dans
la table. En tables locales, ok, mais dans une application normale, il n'y a
pas de tables locales et je me vois mal faire un opendatabase à chaqu e seek
éventuel pour aller récupérer un objet table. l'utilisation du se ek est très
très limitée et pour moi, on ne peut pas parler de performances ave c un tel
outil.



Le fait est que plus on met d'étapes, plus il faut cogiter si on ne veu t
pas que ça traîne trop ...

D'ailleurs, ça me donne des idées (que j'aurais dû avoir avant,
d'ailleurs) : garder la base externe ouverte en public dans le
formulaire de menu principal, ça risquerait de faire gagner du temps,
par rapport à la rouvrir à chaque fois qu'on bouge le petit doigt.

Raymond [mvp]
Le #6296091
Bonsoir.

oui, à condition de ne pas faire du DAO mais ADO, et utiliser toujours la
même connexion, sinon retour à la case départ.

--
@+
Raymond Access MVP http://www.OfficeSystemAccess.com/
http://officesystem.access.over-blog.com/
http://officesystem.access.free.fr/wiki/
Pour débuter sur le forum: http://www.mpfa.info/

Venez découvrir Open XML, le nouveau format de fichier de la suite Office !
http://www.comscamp.com/Tracker/Redirect.ashx?linkidÿ71c7f3-78e8-4371-abaf-b73c259e58db


"Gloops" %23lpSNw%
Raymond [mvp] a écrit, le 30/06/2007 14:20 :
Il faut bien s'entendre sur le mot performance. l'article ne traite que
des
tables locales, d'une part, et ne parle pas des déplacements ultérieurs
dans
la table. En tables locales, ok, mais dans une application normale, il n'y
a
pas de tables locales et je me vois mal faire un opendatabase à chaque
seek
éventuel pour aller récupérer un objet table. l'utilisation du seek est
très
très limitée et pour moi, on ne peut pas parler de performances avec un
tel
outil.



Le fait est que plus on met d'étapes, plus il faut cogiter si on ne veut
pas que ça traîne trop ...

D'ailleurs, ça me donne des idées (que j'aurais dû avoir avant,
d'ailleurs) : garder la base externe ouverte en public dans le
formulaire de menu principal, ça risquerait de faire gagner du temps,
par rapport à la rouvrir à chaque fois qu'on bouge le petit doigt.

Gloops
Le #6295501
Raymond [mvp] a écrit, le 01/07/2007 22:24 :
Bonsoir.

oui, à condition de ne pas faire du DAO mais ADO, et utiliser toujour s la
même connexion, sinon retour à la case départ.



Ah, ça, je dois reconnaître que ça me serait passé au-dessus ...

Publicité
Poster une réponse
Anonyme