dans une table où j'ai un IDcas, une datExposition et toute une série de
variable accessoire, je souhaiterais récupérer le rang de chaque
datExposition. Aussi faudrait-il que le rang se réinitialise à 1 à chaque
nouveau IDcas.
Évidemment, dans un état c'est plutôt facile mais j'ai besoin du rang dans
une requête pour éventuellement coder en dur dans une table.
Une recherche dans l'historique me propose ceci (à insérer dans ma requête)
Toutefois j'aimerais que le compteur se rénitialise en fonction du regroupement.
Complète par un:
# & And Champ=" & Me.ChampDuRegroupement)
Humm ?
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
Ma Dalton
Salut Pierre, j'aurais donc dans ma requête: rang: CpteDom("*";"Table1";"[datExposition] <= #" & Format([datExposition];"mm/jj/aaaa") & "#" Et "[IDcas]=" & [IDcas])
malheureusement, cela donne pour chaque ligne, un rang équivalent au nombre total de IDcas
Toutefois j'aimerais que le compteur se rénitialise en fonction du regroupement.
Complète par un:
# & And Champ=" & Me.ChampDuRegroupement)
Humm ?
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
Salut Pierre,
j'aurais donc dans ma requête:
rang: CpteDom("*";"Table1";"[datExposition] <= #" &
Format([datExposition];"mm/jj/aaaa") & "#" Et "[IDcas]=" & [IDcas])
malheureusement, cela donne pour chaque ligne, un rang équivalent au nombre
total de IDcas
Salut Pierre, j'aurais donc dans ma requête: rang: CpteDom("*";"Table1";"[datExposition] <= #" & Format([datExposition];"mm/jj/aaaa") & "#" Et "[IDcas]=" & [IDcas])
malheureusement, cela donne pour chaque ligne, un rang équivalent au nombre total de IDcas
Toutefois j'aimerais que le compteur se rénitialise en fonction du regroupement.
Complète par un:
# & And Champ=" & Me.ChampDuRegroupement)
Humm ?
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
Eric
Bonjour,
Je pense qu'il faut que tu corriges comme suit :
& "# AND [IDcas]=" & [IDcas])
au lieu de : & "#" Et "[IDcas]=" & [IDcas])
A+ Eric
"Ma Dalton" écrivait news:eHy0GZ#:
Salut Pierre, j'aurais donc dans ma requête: rang: CpteDom("*";"Table1";"[datExposition] <= #" & Format([datExposition];"mm/jj/aaaa") & "#" Et "[IDcas]=" & [IDcas])
malheureusement, cela donne pour chaque ligne, un rang équivalent au nombre total de IDcas
Toutefois j'aimerais que le compteur se rénitialise en fonction du regroupement.
Complète par un:
# & And Champ=" & Me.ChampDuRegroupement)
Humm ?
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
Bonjour,
Je pense qu'il faut que tu corriges comme suit :
& "# AND [IDcas]=" & [IDcas])
au lieu de :
& "#" Et "[IDcas]=" & [IDcas])
A+
Eric
"Ma Dalton" <Rantanplan@farwest.net> écrivait
news:eHy0GZ#0EHA.1652@TK2MSFTNGP11.phx.gbl:
Salut Pierre,
j'aurais donc dans ma requête:
rang: CpteDom("*";"Table1";"[datExposition] <= #" &
Format([datExposition];"mm/jj/aaaa") & "#" Et "[IDcas]=" & [IDcas])
malheureusement, cela donne pour chaque ligne, un rang équivalent au
nombre total de IDcas
Salut Pierre, j'aurais donc dans ma requête: rang: CpteDom("*";"Table1";"[datExposition] <= #" & Format([datExposition];"mm/jj/aaaa") & "#" Et "[IDcas]=" & [IDcas])
malheureusement, cela donne pour chaque ligne, un rang équivalent au nombre total de IDcas
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide! Tu sais ma table réelle contient 90000 records donc il y a 90000 DCount qui cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé durant 2h et à peine 10% de la progression avait avancée. Il faudra donc changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la valeur du rang dans une nouvelle variable créé par programmation dans la table d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez facilement.
A+
"3stone" a écrit dans le message de news:
"Ma Dalton"
mais compte tenu que dans mon exemple, IDcas est string, voici ce qui fonctionne
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount
fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide!
Tu sais ma table réelle contient 90000 records donc il y a 90000 DCount qui
cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé
durant 2h et à peine 10% de la progression avait avancée. Il faudra donc
changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la valeur
du rang dans une nouvelle variable créé par programmation dans la table
d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez
facilement.
A+
"3stone" <3_stone_@_sky_net.be> a écrit dans le message de news:
eMPApPB1EHA.2568@TK2MSFTNGP11.phx.gbl...
"Ma Dalton"
mais compte tenu que dans mon exemple, IDcas est string, voici ce qui
fonctionne
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide! Tu sais ma table réelle contient 90000 records donc il y a 90000 DCount qui cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé durant 2h et à peine 10% de la progression avait avancée. Il faudra donc changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la valeur du rang dans une nouvelle variable créé par programmation dans la table d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez facilement.
A+
"3stone" a écrit dans le message de news:
"Ma Dalton"
mais compte tenu que dans mon exemple, IDcas est string, voici ce qui fonctionne
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide!
Effectivement, les fonctions de domaine sont (relativement ;) simple à mettre en oeuvre (pas de recordset à manipuler), mais lente lorsque dans une requête...
Tu sais ma table réelle contient 90000 records
Aieeee !
donc il y a 90000 DCount qui cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé durant 2h et à peine 10% de la progression avait avancée. Il faudra donc changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la valeur du rang dans une nouvelle variable créé par programmation dans la table d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez facilement.
Et tu le recherche comment alors, ce rang ?
Si tu crée une table temporaire, avec les enregistrements classés avec un "OrderBy" qui va bien. Ensuite, tu "numérote" avec une boucle...
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
Salut,
"Ma Dalton"
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount
fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide!
Effectivement, les fonctions de domaine sont (relativement ;) simple
à mettre en oeuvre (pas de recordset à manipuler), mais lente
lorsque dans une requête...
Tu sais ma table réelle contient 90000 records
Aieeee !
donc il y a 90000 DCount qui
cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé
durant 2h et à peine 10% de la progression avait avancée. Il faudra donc
changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la valeur
du rang dans une nouvelle variable créé par programmation dans la table
d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez
facilement.
Et tu le recherche comment alors, ce rang ?
Si tu crée une table temporaire, avec les enregistrements classés
avec un "OrderBy" qui va bien.
Ensuite, tu "numérote" avec une boucle...
--
A+
Pierre (3stone) Access MVP
~~~~~~~~~~~~~~~~~~~~~~~
http://users.skynet.be/mpfa
http://users.skynet.be/accesshome
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide!
Effectivement, les fonctions de domaine sont (relativement ;) simple à mettre en oeuvre (pas de recordset à manipuler), mais lente lorsque dans une requête...
Tu sais ma table réelle contient 90000 records
Aieeee !
donc il y a 90000 DCount qui cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé durant 2h et à peine 10% de la progression avait avancée. Il faudra donc changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la valeur du rang dans une nouvelle variable créé par programmation dans la table d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez facilement.
Et tu le recherche comment alors, ce rang ?
Si tu crée une table temporaire, avec les enregistrements classés avec un "OrderBy" qui va bien. Ensuite, tu "numérote" avec une boucle...
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
Ma Dalton
exact,
après le tri, je songe boucler sur chaque record pour tester si on traite toujours du même sous ensemble (condition), si oui le compteur fait +1 sinon =0 et ainsi de suite jusqu'à EOF. au travers cela il y aura écriture de la valeur du rang (compteur) dans une nouvelle variable du recordset.
Il y a quelques année, j'étais pas pire pour ce genre de traitement sur des très grosses BD mal structurées. En fait à l'époque notre bureau chef acheminait à chaque bureau régional des disquettes de données issues de nos systèmes opérationnels centraux (de l'époque). Le format des fichiers sur disquettes était en fait le résultat d'analyse croisée dumpé dans un fichier texte. Ce n'était pas génial pour le traitement puisque par exemple, si chaque colonne représentait une donnée annuelle, il devenait impossible de faire un select annee85. J'avais donc produit un programme (dans ce temps c'était avec dbase 3) qui à l'aide de boucles arrivait à tout reformatter la structure de la table de manière à obtenir une seule colonne de données et quelques autres pour les variables de critères.
bref fini la jasette et je me met au travail ... sauf que ma soirée TV commence bientôt http://www.belleetbum.tv/ (100% musique de tous genre. Il y a souvent de petit bijoux hors des circuit commerciaux...)
A+
"3stone" a écrit dans le message de news: eWrG5%
Salut,
"Ma Dalton"
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide!
Effectivement, les fonctions de domaine sont (relativement ;) simple à mettre en oeuvre (pas de recordset à manipuler), mais lente lorsque dans une requête...
Tu sais ma table réelle contient 90000 records
Aieeee !
donc il y a 90000 DCount qui cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé durant 2h et à peine 10% de la progression avait avancée. Il faudra donc changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la valeur du rang dans une nouvelle variable créé par programmation dans la table d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez facilement.
Et tu le recherche comment alors, ce rang ?
Si tu crée une table temporaire, avec les enregistrements classés avec un "OrderBy" qui va bien. Ensuite, tu "numérote" avec une boucle...
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
exact,
après le tri, je songe boucler sur chaque record pour tester si on traite
toujours du même sous ensemble (condition), si oui le compteur fait +1
sinon =0 et ainsi de suite jusqu'à EOF. au travers cela il y aura écriture
de la valeur du rang (compteur) dans une nouvelle variable du recordset.
Il y a quelques année, j'étais pas pire pour ce genre de traitement sur des
très grosses BD mal structurées. En fait à l'époque notre bureau chef
acheminait à chaque bureau régional des disquettes de données issues de nos
systèmes opérationnels centraux (de l'époque). Le format des fichiers sur
disquettes était en fait le résultat d'analyse croisée dumpé dans un fichier
texte. Ce n'était pas génial pour le traitement puisque par exemple, si
chaque colonne représentait une donnée annuelle, il devenait impossible de
faire un select annee85. J'avais donc produit un programme (dans ce
temps c'était avec dbase 3) qui à l'aide de boucles arrivait à tout
reformatter la structure de la table de manière à obtenir une seule colonne
de données et quelques autres pour les variables de critères.
bref fini la jasette et je me met au travail ... sauf que ma soirée TV
commence bientôt http://www.belleetbum.tv/ (100% musique de tous genre. Il y
a souvent de petit bijoux hors des circuit commerciaux...)
A+
"3stone" <3_stone_@_sky_net.be> a écrit dans le message de news:
eWrG5%23K1EHA.3708@TK2MSFTNGP14.phx.gbl...
Salut,
"Ma Dalton"
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount
fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide!
Effectivement, les fonctions de domaine sont (relativement ;) simple
à mettre en oeuvre (pas de recordset à manipuler), mais lente
lorsque dans une requête...
Tu sais ma table réelle contient 90000 records
Aieeee !
donc il y a 90000 DCount qui
cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé
durant 2h et à peine 10% de la progression avait avancée. Il faudra donc
changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la
valeur
du rang dans une nouvelle variable créé par programmation dans la table
d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez
facilement.
Et tu le recherche comment alors, ce rang ?
Si tu crée une table temporaire, avec les enregistrements classés
avec un "OrderBy" qui va bien.
Ensuite, tu "numérote" avec une boucle...
--
A+
Pierre (3stone) Access MVP
~~~~~~~~~~~~~~~~~~~~~~~
http://users.skynet.be/mpfa
http://users.skynet.be/accesshome
après le tri, je songe boucler sur chaque record pour tester si on traite toujours du même sous ensemble (condition), si oui le compteur fait +1 sinon =0 et ainsi de suite jusqu'à EOF. au travers cela il y aura écriture de la valeur du rang (compteur) dans une nouvelle variable du recordset.
Il y a quelques année, j'étais pas pire pour ce genre de traitement sur des très grosses BD mal structurées. En fait à l'époque notre bureau chef acheminait à chaque bureau régional des disquettes de données issues de nos systèmes opérationnels centraux (de l'époque). Le format des fichiers sur disquettes était en fait le résultat d'analyse croisée dumpé dans un fichier texte. Ce n'était pas génial pour le traitement puisque par exemple, si chaque colonne représentait une donnée annuelle, il devenait impossible de faire un select annee85. J'avais donc produit un programme (dans ce temps c'était avec dbase 3) qui à l'aide de boucles arrivait à tout reformatter la structure de la table de manière à obtenir une seule colonne de données et quelques autres pour les variables de critères.
bref fini la jasette et je me met au travail ... sauf que ma soirée TV commence bientôt http://www.belleetbum.tv/ (100% musique de tous genre. Il y a souvent de petit bijoux hors des circuit commerciaux...)
A+
"3stone" a écrit dans le message de news: eWrG5%
Salut,
"Ma Dalton"
Jusqu'ici tout n'a été que théorique sur une table bidon et le DCount fonctionne parfaitement dans ce contexte. Mais ce n'est pas très rapide!
Effectivement, les fonctions de domaine sont (relativement ;) simple à mettre en oeuvre (pas de recordset à manipuler), mais lente lorsque dans une requête...
Tu sais ma table réelle contient 90000 records
Aieeee !
donc il y a 90000 DCount qui cherche dans une étendue de 90000 records. Hier soir, j'ai laissé roulé durant 2h et à peine 10% de la progression avait avancée. Il faudra donc changé de tactique.
je songe plutôt à le faire par boucle dans une SUB puis d'écrire la valeur du rang dans une nouvelle variable créé par programmation dans la table d'origine. J'imagine qu'avec un peu de temps j'y parviendrai assez facilement.
Et tu le recherche comment alors, ce rang ?
Si tu crée une table temporaire, avec les enregistrements classés avec un "OrderBy" qui va bien. Ensuite, tu "numérote" avec une boucle...
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
