Voilà le choix qui se présente lorsqu'il s'agit du type de jeu
d'enregistrements :
- avec un jeu d'enregistrements de type Dynaset, je dispose de la
propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le
numéro d'enregistrement en cours d'affichage ; pour atteindre un
enregistrement d'après la valeur d'un champ, il faut tous les parcourir
en séquentiel jusqu'à tomber sur le bon
- avec un jeu d'enregistrements de type Table, je dispose de la méthode
Seek, qui me permet de sélectionner un enregistrement directement
d'après la valeur de l'index, sans avoir à parcourir en séquentiel comme
c'est le cas avec le Dynaset, mais je ne peux pas annoncer le numéro
d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt
devient mystérieux)
- il existe aussi d'autres types mais pas très adaptés si on veut
pouvoir modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant
la chaude et la froide, ou est-ce que je suis passé à côté de quelque
chose ?
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
Christian Hubert-Hugoud
Salut,
Il me semble qu'il y a à prendre en compte d'autres considérations, suivant ma façon de programmer...
J'aime avoir une clé primaire sous forme de long (numeroauto) dans mes tables. Cela me permet de la stocker facilement (par exemple dans l'itemdata d'une listbox) et ainsi de pouvoir me repositionner dessus immédiatement.
A partir de ce moment là, afficher le n° d'enregistrement devient un jeu d'enfant, puisque c'est la clé primaire, sachant que ce numéro est un identifiant d'enregistrement, mais pas de position (quand les numéroauto sont détruits, il ne sont pas ré-utilisés par la suite).
Ensuite, travailler sur la table directement était dans le passé assez délicat et source de bugs. J'avais décidé alors de passer par des recordset systématiquement, avec une instruction sql pour les remplir. Cela fonctionne parfaitement bien. Même s'il s'agissait de travailler sur une table, je créais un recordset qui était en fait une photo de la table.
Hope this helps...
Christian
"Gloops" a écrit dans le message de news: 4289c6f7$0$1214$
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu d'enregistrements : - avec un jeu d'enregistrements de type Dynaset, je dispose de la propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le numéro d'enregistrement en cours d'affichage ; pour atteindre un enregistrement d'après la valeur d'un champ, il faut tous les parcourir en séquentiel jusqu'à tomber sur le bon - avec un jeu d'enregistrements de type Table, je dispose de la méthode Seek, qui me permet de sélectionner un enregistrement directement d'après la valeur de l'index, sans avoir à parcourir en séquentiel comme c'est le cas avec le Dynaset, mais je ne peux pas annoncer le numéro d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt devient mystérieux) - il existe aussi d'autres types mais pas très adaptés si on veut pouvoir modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant la chaude et la froide, ou est-ce que je suis passé à côté de quelque chose ?
Salut,
Il me semble qu'il y a à prendre en compte d'autres considérations, suivant
ma façon de programmer...
J'aime avoir une clé primaire sous forme de long (numeroauto) dans mes
tables. Cela me permet de la stocker facilement (par exemple dans l'itemdata
d'une listbox) et ainsi de pouvoir me repositionner dessus immédiatement.
A partir de ce moment là, afficher le n° d'enregistrement devient un jeu
d'enfant, puisque c'est la clé primaire, sachant que ce numéro est un
identifiant d'enregistrement, mais pas de position (quand les numéroauto
sont détruits, il ne sont pas ré-utilisés par la suite).
Ensuite, travailler sur la table directement était dans le passé assez
délicat et source de bugs. J'avais décidé alors de passer par des recordset
systématiquement, avec une instruction sql pour les remplir. Cela fonctionne
parfaitement bien. Même s'il s'agissait de travailler sur une table, je
créais un recordset qui était en fait une photo de la table.
Hope this helps...
Christian
"Gloops" <gloops@niark.fr> a écrit dans le message de news:
4289c6f7$0$1214$8fcfb975@news.wanadoo.fr...
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu
d'enregistrements :
- avec un jeu d'enregistrements de type Dynaset, je dispose de la
propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le
numéro d'enregistrement en cours d'affichage ; pour atteindre un
enregistrement d'après la valeur d'un champ, il faut tous les parcourir en
séquentiel jusqu'à tomber sur le bon
- avec un jeu d'enregistrements de type Table, je dispose de la méthode
Seek, qui me permet de sélectionner un enregistrement directement d'après
la valeur de l'index, sans avoir à parcourir en séquentiel comme c'est le
cas avec le Dynaset, mais je ne peux pas annoncer le numéro
d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt
devient mystérieux)
- il existe aussi d'autres types mais pas très adaptés si on veut pouvoir
modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant
la chaude et la froide, ou est-ce que je suis passé à côté de quelque
chose ?
Il me semble qu'il y a à prendre en compte d'autres considérations, suivant ma façon de programmer...
J'aime avoir une clé primaire sous forme de long (numeroauto) dans mes tables. Cela me permet de la stocker facilement (par exemple dans l'itemdata d'une listbox) et ainsi de pouvoir me repositionner dessus immédiatement.
A partir de ce moment là, afficher le n° d'enregistrement devient un jeu d'enfant, puisque c'est la clé primaire, sachant que ce numéro est un identifiant d'enregistrement, mais pas de position (quand les numéroauto sont détruits, il ne sont pas ré-utilisés par la suite).
Ensuite, travailler sur la table directement était dans le passé assez délicat et source de bugs. J'avais décidé alors de passer par des recordset systématiquement, avec une instruction sql pour les remplir. Cela fonctionne parfaitement bien. Même s'il s'agissait de travailler sur une table, je créais un recordset qui était en fait une photo de la table.
Hope this helps...
Christian
"Gloops" a écrit dans le message de news: 4289c6f7$0$1214$
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu d'enregistrements : - avec un jeu d'enregistrements de type Dynaset, je dispose de la propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le numéro d'enregistrement en cours d'affichage ; pour atteindre un enregistrement d'après la valeur d'un champ, il faut tous les parcourir en séquentiel jusqu'à tomber sur le bon - avec un jeu d'enregistrements de type Table, je dispose de la méthode Seek, qui me permet de sélectionner un enregistrement directement d'après la valeur de l'index, sans avoir à parcourir en séquentiel comme c'est le cas avec le Dynaset, mais je ne peux pas annoncer le numéro d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt devient mystérieux) - il existe aussi d'autres types mais pas très adaptés si on veut pouvoir modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant la chaude et la froide, ou est-ce que je suis passé à côté de quelque chose ?
Gloops
Salut,
Ben ... oui, c'est ce que je fais. Enfin je veux dire, je crée un jeu d'enregistrements systématiquement, d'ailleurs quand j'ai voulu faire autrement on m'a dit que la table n'avait pas de champs ... (du moins l'objet TableDef, et du moins je ne pouvais pas lire leur valeur). Bref.
Comme tu dis si justement, la clef automatique n'est pas nécessairement le numéro d'enregistrement, en raison de trous de séquence possibles (et pas si rares que ça).
Alors, il y a bien la possibilité d'écrire une fonction qui retourne le numéro d'enregistrement d'après la clef, en ouvrant un Dynaset sur la requête pour le parcourir en séquentiel, et pointer dessus par Seek dans le formulaire, qui utilise un jeu de type table.
ça permet de concilier les avantages des deux, en évitant le défilement séquentiel du formulaire, qui ne manque pas de générer des procédures événementielles.
D'ailleurs il y a encore une finesse à mettre au point, car c'est sous Access que j'ai joué à ça, et là on a DoCmd.Goto si je me rappelle bien, pour sélectionner un enregistrement dans un formulaire d'après son numéro d'ordre dans le résultat de la requête source. Il va falloir que je trouve l'équivalent sous VB6, si quelqu'un peut me mettre le nez dessus ça peut gagner du temps ...
Je me demandais si pour arriver au même résultat (défilement rapide et affichage du numéro d'ordre de l'enregistrement), il n'existe pas plus léger que cette gymnastique.
Pour le moment j'en suis à initialiser un booléen qui neutralise les procédures événementielles. Il y a des finesses de mise en oeuvre, d'ailleurs, mais là le sujet c'est l'utilisation de plusieurs sous-formulaires dans un formulaire MDI, donc on y reviendra.
Voilà. J'arrive au résultat, mais je me demande si c'est obligé d'avoir un style lourdingue pour la sélection d'enregistrement. Indépendamment de l'ouverture de plusieurs sous-formulaires, qui sous VB6, n'est effectivement pas très orthodoxe.
Christian Hubert-Hugoud a écrit, le 17/05/2005 13:58 :
Salut,
Il me semble qu'il y a à prendre en compte d'autres considérations, suivant ma façon de programmer...
J'aime avoir une clé primaire sous forme de long (numeroauto) dans mes tables. Cela me permet de la stocker facilement (par exemple dans l'itemdata d'une listbox) et ainsi de pouvoir me repositionner dessus immédiatement.
A partir de ce moment là, afficher le n° d'enregistrement devient un jeu d'enfant, puisque c'est la clé primaire, sachant que ce numéro est un identifiant d'enregistrement, mais pas de position (quand les numéroauto sont détruits, il ne sont pas ré-utilisés par la suite).
Ensuite, travailler sur la table directement était dans le passé assez délicat et source de bugs. J'avais décidé alors de passer par des recordset systématiquement, avec une instruction sql pour les remplir. Cela fonctionne parfaitement bien. Même s'il s'agissait de travailler sur une table, je créais un recordset qui était en fait une photo de la table.
Hope this helps...
Christian
"Gloops" a écrit dans le message de news: 4289c6f7$0$1214$
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu d'enregistrements : - avec un jeu d'enregistrements de type Dynaset, je dispose de la propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le numéro d'enregistrement en cours d'affichage ; pour atteindre un enregistrement d'après la valeur d'un champ, il faut tous les parcourir en séquentiel jusqu'à tomber sur le bon - avec un jeu d'enregistrements de type Table, je dispose de la méthode Seek, qui me permet de sélectionner un enregistrement directement d'après la valeur de l'index, sans avoir à parcourir en séquentiel comme c'est le cas avec le Dynaset, mais je ne peux pas annoncer le numéro d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt devient mystérieux) - il existe aussi d'autres types mais pas très adaptés si on veut pouvoir modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant la chaude et la froide, ou est-ce que je suis passé à côté de quelque chose ?
Salut,
Ben ... oui, c'est ce que je fais. Enfin je veux dire, je crée un jeu
d'enregistrements systématiquement, d'ailleurs quand j'ai voulu faire
autrement on m'a dit que la table n'avait pas de champs ... (du moins
l'objet TableDef, et du moins je ne pouvais pas lire leur valeur). Bref.
Comme tu dis si justement, la clef automatique n'est pas nécessairement
le numéro d'enregistrement, en raison de trous de séquence possibles (et
pas si rares que ça).
Alors, il y a bien la possibilité d'écrire une fonction qui retourne le
numéro d'enregistrement d'après la clef, en ouvrant un Dynaset sur la
requête pour le parcourir en séquentiel, et pointer dessus par Seek dans
le formulaire, qui utilise un jeu de type table.
ça permet de concilier les avantages des deux, en évitant le défilement
séquentiel du formulaire, qui ne manque pas de générer des procédures
événementielles.
D'ailleurs il y a encore une finesse à mettre au point, car c'est sous
Access que j'ai joué à ça, et là on a DoCmd.Goto si je me rappelle bien,
pour sélectionner un enregistrement dans un formulaire d'après son
numéro d'ordre dans le résultat de la requête source. Il va falloir que
je trouve l'équivalent sous VB6, si quelqu'un peut me mettre le nez
dessus ça peut gagner du temps ...
Je me demandais si pour arriver au même résultat (défilement rapide et
affichage du numéro d'ordre de l'enregistrement), il n'existe pas plus
léger que cette gymnastique.
Pour le moment j'en suis à initialiser un booléen qui neutralise les
procédures événementielles. Il y a des finesses de mise en oeuvre,
d'ailleurs, mais là le sujet c'est l'utilisation de plusieurs
sous-formulaires dans un formulaire MDI, donc on y reviendra.
Voilà. J'arrive au résultat, mais je me demande si c'est obligé d'avoir
un style lourdingue pour la sélection d'enregistrement. Indépendamment
de l'ouverture de plusieurs sous-formulaires, qui sous VB6, n'est
effectivement pas très orthodoxe.
Christian Hubert-Hugoud a écrit, le 17/05/2005 13:58 :
Salut,
Il me semble qu'il y a à prendre en compte d'autres considérations, suivant
ma façon de programmer...
J'aime avoir une clé primaire sous forme de long (numeroauto) dans mes
tables. Cela me permet de la stocker facilement (par exemple dans l'itemdata
d'une listbox) et ainsi de pouvoir me repositionner dessus immédiatement.
A partir de ce moment là, afficher le n° d'enregistrement devient un jeu
d'enfant, puisque c'est la clé primaire, sachant que ce numéro est un
identifiant d'enregistrement, mais pas de position (quand les numéroauto
sont détruits, il ne sont pas ré-utilisés par la suite).
Ensuite, travailler sur la table directement était dans le passé assez
délicat et source de bugs. J'avais décidé alors de passer par des recordset
systématiquement, avec une instruction sql pour les remplir. Cela fonctionne
parfaitement bien. Même s'il s'agissait de travailler sur une table, je
créais un recordset qui était en fait une photo de la table.
Hope this helps...
Christian
"Gloops" <gloops@niark.fr> a écrit dans le message de news:
4289c6f7$0$1214$8fcfb975@news.wanadoo.fr...
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu
d'enregistrements :
- avec un jeu d'enregistrements de type Dynaset, je dispose de la
propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le
numéro d'enregistrement en cours d'affichage ; pour atteindre un
enregistrement d'après la valeur d'un champ, il faut tous les parcourir en
séquentiel jusqu'à tomber sur le bon
- avec un jeu d'enregistrements de type Table, je dispose de la méthode
Seek, qui me permet de sélectionner un enregistrement directement d'après
la valeur de l'index, sans avoir à parcourir en séquentiel comme c'est le
cas avec le Dynaset, mais je ne peux pas annoncer le numéro
d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt
devient mystérieux)
- il existe aussi d'autres types mais pas très adaptés si on veut pouvoir
modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant
la chaude et la froide, ou est-ce que je suis passé à côté de quelque
chose ?
Ben ... oui, c'est ce que je fais. Enfin je veux dire, je crée un jeu d'enregistrements systématiquement, d'ailleurs quand j'ai voulu faire autrement on m'a dit que la table n'avait pas de champs ... (du moins l'objet TableDef, et du moins je ne pouvais pas lire leur valeur). Bref.
Comme tu dis si justement, la clef automatique n'est pas nécessairement le numéro d'enregistrement, en raison de trous de séquence possibles (et pas si rares que ça).
Alors, il y a bien la possibilité d'écrire une fonction qui retourne le numéro d'enregistrement d'après la clef, en ouvrant un Dynaset sur la requête pour le parcourir en séquentiel, et pointer dessus par Seek dans le formulaire, qui utilise un jeu de type table.
ça permet de concilier les avantages des deux, en évitant le défilement séquentiel du formulaire, qui ne manque pas de générer des procédures événementielles.
D'ailleurs il y a encore une finesse à mettre au point, car c'est sous Access que j'ai joué à ça, et là on a DoCmd.Goto si je me rappelle bien, pour sélectionner un enregistrement dans un formulaire d'après son numéro d'ordre dans le résultat de la requête source. Il va falloir que je trouve l'équivalent sous VB6, si quelqu'un peut me mettre le nez dessus ça peut gagner du temps ...
Je me demandais si pour arriver au même résultat (défilement rapide et affichage du numéro d'ordre de l'enregistrement), il n'existe pas plus léger que cette gymnastique.
Pour le moment j'en suis à initialiser un booléen qui neutralise les procédures événementielles. Il y a des finesses de mise en oeuvre, d'ailleurs, mais là le sujet c'est l'utilisation de plusieurs sous-formulaires dans un formulaire MDI, donc on y reviendra.
Voilà. J'arrive au résultat, mais je me demande si c'est obligé d'avoir un style lourdingue pour la sélection d'enregistrement. Indépendamment de l'ouverture de plusieurs sous-formulaires, qui sous VB6, n'est effectivement pas très orthodoxe.
Christian Hubert-Hugoud a écrit, le 17/05/2005 13:58 :
Salut,
Il me semble qu'il y a à prendre en compte d'autres considérations, suivant ma façon de programmer...
J'aime avoir une clé primaire sous forme de long (numeroauto) dans mes tables. Cela me permet de la stocker facilement (par exemple dans l'itemdata d'une listbox) et ainsi de pouvoir me repositionner dessus immédiatement.
A partir de ce moment là, afficher le n° d'enregistrement devient un jeu d'enfant, puisque c'est la clé primaire, sachant que ce numéro est un identifiant d'enregistrement, mais pas de position (quand les numéroauto sont détruits, il ne sont pas ré-utilisés par la suite).
Ensuite, travailler sur la table directement était dans le passé assez délicat et source de bugs. J'avais décidé alors de passer par des recordset systématiquement, avec une instruction sql pour les remplir. Cela fonctionne parfaitement bien. Même s'il s'agissait de travailler sur une table, je créais un recordset qui était en fait une photo de la table.
Hope this helps...
Christian
"Gloops" a écrit dans le message de news: 4289c6f7$0$1214$
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu d'enregistrements : - avec un jeu d'enregistrements de type Dynaset, je dispose de la propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le numéro d'enregistrement en cours d'affichage ; pour atteindre un enregistrement d'après la valeur d'un champ, il faut tous les parcourir en séquentiel jusqu'à tomber sur le bon - avec un jeu d'enregistrements de type Table, je dispose de la méthode Seek, qui me permet de sélectionner un enregistrement directement d'après la valeur de l'index, sans avoir à parcourir en séquentiel comme c'est le cas avec le Dynaset, mais je ne peux pas annoncer le numéro d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt devient mystérieux) - il existe aussi d'autres types mais pas très adaptés si on veut pouvoir modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant la chaude et la froide, ou est-ce que je suis passé à côté de quelque chose ?
Gloops
Bon, ben y en a pas beaucoup qui suivent ...
Avec un Dynaset, on peut accéder à un enregistrement directement d'après la clef unique en utilisant l'instruction Rs.FindFirst.
Et on dispose en plus de AbsolutePosition.
Gloops a écrit, le 17/05/2005 12:27 :
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu d'enregistrements : - avec un jeu d'enregistrements de type Dynaset, je dispose de la propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le numéro d'enregistrement en cours d'affichage ; pour atteindre un enregistrement d'après la valeur d'un champ, il faut tous les parcourir en séquentiel jusqu'à tomber sur le bon - avec un jeu d'enregistrements de type Table, je dispose de la méthode Seek, qui me permet de sélectionner un enregistrement directement d'après la valeur de l'index, sans avoir à parcourir en séquentiel comme c'est le cas avec le Dynaset, mais je ne peux pas annoncer le numéro d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt devient mystérieux) - il existe aussi d'autres types mais pas très adaptés si on veut pouvoir modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant la chaude et la froide, ou est-ce que je suis passé à côté de quelque chose ?
Bon, ben y en a pas beaucoup qui suivent ...
Avec un Dynaset, on peut accéder à un enregistrement directement d'après
la clef unique en utilisant l'instruction Rs.FindFirst.
Et on dispose en plus de AbsolutePosition.
Gloops a écrit, le 17/05/2005 12:27 :
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu
d'enregistrements :
- avec un jeu d'enregistrements de type Dynaset, je dispose de la
propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le
numéro d'enregistrement en cours d'affichage ; pour atteindre un
enregistrement d'après la valeur d'un champ, il faut tous les parcourir
en séquentiel jusqu'à tomber sur le bon
- avec un jeu d'enregistrements de type Table, je dispose de la méthode
Seek, qui me permet de sélectionner un enregistrement directement
d'après la valeur de l'index, sans avoir à parcourir en séquentiel comme
c'est le cas avec le Dynaset, mais je ne peux pas annoncer le numéro
d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt
devient mystérieux)
- il existe aussi d'autres types mais pas très adaptés si on veut
pouvoir modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant
la chaude et la froide, ou est-ce que je suis passé à côté de quelque
chose ?
Avec un Dynaset, on peut accéder à un enregistrement directement d'après la clef unique en utilisant l'instruction Rs.FindFirst.
Et on dispose en plus de AbsolutePosition.
Gloops a écrit, le 17/05/2005 12:27 :
Bonjour tout le monde,
Voilà le choix qui se présente lorsqu'il s'agit du type de jeu d'enregistrements : - avec un jeu d'enregistrements de type Dynaset, je dispose de la propriété AbsolutePosition, qui me permet d'annoncer à l'utilisateur le numéro d'enregistrement en cours d'affichage ; pour atteindre un enregistrement d'après la valeur d'un champ, il faut tous les parcourir en séquentiel jusqu'à tomber sur le bon - avec un jeu d'enregistrements de type Table, je dispose de la méthode Seek, qui me permet de sélectionner un enregistrement directement d'après la valeur de l'index, sans avoir à parcourir en séquentiel comme c'est le cas avec le Dynaset, mais je ne peux pas annoncer le numéro d'enregistrement (sauf à parcourir en séquentiel mais alors l'intérêt devient mystérieux) - il existe aussi d'autres types mais pas très adaptés si on veut pouvoir modifier les données.
Est-ce que je suis juste en train de découvrir l'eau tiède en mélangeant la chaude et la froide, ou est-ce que je suis passé à côté de quelque chose ?
