Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Applications Microsoft Office Access Versions Access : Index, Seek ...

Versions Access : Index, Seek ...

10 réponses
Avatar
Gloops
Bonjour tout le monde,

Apr=E8s m'=EAtre heurt=E9 un certain nombre de fois =E0 l'erreur 3251 (op=
=E9ration=20
non autoris=E9e pour ce type d'objet) en appliquant sous Access 2000 les =

syntaxes auxquelles j'=E9tais habitu=E9 sous Access 95 et 97, j'essaie de=
=20
trouver, quelque part, une synth=E8se sur les types de jeux=20
d'enregistrements qui acceptent la propri=E9t=E9 Index et la syntaxe Seek=
=20
qui va avec : Rs.Seek "=3D", Cl=E91, Cl=E92

Il serait int=E9ressant entre autres de savoir sur quoi on peut les ouvri=
r=20
(une table, une requ=EAte, ordonn=E9e ou non, ...)

Dans la doc il m'a sembl=E9 voir que dbOpenDynaset faisait l'affaire pour=
=20
d=E9signer 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=E9matiquement la d=E9clarati=
on=20
tardive, du style

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

Je ne suis pas le premier =E0 trouver qu'un gestionnaire de bases de=20
donn=E9es qui ne conna=EEt pas l'objet Database sans qu'on aille lui=20
chercher un dictionnaire au coup par coup (en pr=E9cisant les r=E9f=E9ren=
ces),=20
=E7a repr=E9sente ... une certaine gymnastique de l'esprit. Je ne sais pa=
s=20
si tout le monde retombe sur le tapis dans ce genre d'exercice,=20
peut-=EAtre quelqu'un voit-il un =E9claircissement =E0 apporter.

Pour utiliser l'autre syntaxe de Seek (Rs.Seek Array(clefs),=20
adSeekAfterEQ), dans les cas o=F9 les champs varient d'un appel =E0 l'aut=
re,=20
j'ai bricol=E9 une fonction qui va chercher les champs dans un index pour=
=20
les comparer un =E0 un. Dans la premi=E8re utilisation que j'en ai faite,=
=20
sur une table, =E7a marche bien, apr=E8s quand il s'est agi d'utiliser =E7=
a=20
sur une requ=EAte avec s=E9lection, je me suis fait jeter. Je risque donc=
=20
d'avoir =E0 passer un autre argument qui fournisse les champs =E0 utilise=
r,=20
=E0 moins que quelqu'un voie une id=E9e lumineuse pour l'=E9viter, dans l=
'id=E9e=20
que si on a moins d'arguments =E0 passer pour faire la m=EAme chose, =E7a=
=20
risque d'=EAtre plus commode =E0 appeler (=E0 =E9crire, bien entendu, c'e=
st une=20
autre affaire).

Voil=E0, si quelqu'un me voit aller droit dans le foss=E9, il peut le dir=
e ...
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Raymond [mvp]
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" a écrit dans le message de news:

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 ...
Avatar
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 "=" 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 ...

Avatar
Raymond [mvp]
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" a écrit dans le message de news:
%
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 ...

Avatar
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 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.



Avatar
Raymond [mvp]
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" a écrit dans le message de news:

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 ?
Avatar
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 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

Avatar
Raymond [mvp]
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" a écrit dans le message de news:

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

Avatar
Gloops
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.

Avatar
Raymond [mvp]
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" a écrit dans le message de news:
%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.

Avatar
Gloops
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 ...