Un fichier d'une application qui contient entre-autre un Code de client et
un Solde par Client doit absolument conserver sa séquence chronologique.
Avant le prochain ajout, le dernier solde d'un client précis est récupéré et
on continue l'ajout de nouvelles transactions pour ce client.
Ce fichier sera "nettoyé" à l'occasion - c'est à dire que des
enregistrements seront supprimés par blocs laissant de gros "trous" dans le
fichier (qui seront automatiquement "bouchés" éventuellement par la
réindexation ou par HAjoute()).
Quand je travaillais avec les fichiers .Dbf il n'y avait aucun problème
puisque les ajouts se faisaient toujours physiquement un après l'autre (les
enregistrements supprimés n'étaient que "marqués" comme tel). Mais Windev a
une gestion intégrée des enregistrements vides qui sont remplis à chaque
HAjoute - ce qui fait que les enregistrements ajoutés peuvent se retrouver
n'importe où dans le fichier - et un HLitRechercheDernier() lit le dernier
enregistrement physique... qui n'est pas nécessairement le dernier
enregistrement pour un client précis.
Pour récupérer le dernier Solde d'un client j'ai donc conclut que je devais
ajouter une rubrique Identifiant automatique (une clef unique par concept).
J'ai fait quelques tests avec le code suivant;
HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient)
HChangeClé(MonFichier,IDAuto,hRespecteFiltre)
HLitDernier(MonFichier)
SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON
mDernierSolde=0.00
HDésactiveFiltre(MonFichier)
Ça semble bien fonctionner de cette façon mais j'aimerais l'avis de
personnes plus expérimentées. Il me semble que ça fait beaucoup de code pour
juste aller chercher une simple information. Et je veux être certain que ça
va bien fonctionner avec des milliers d'enregistrements.
Je présume que je pourrais aussi avoir une rubrique composée du Code du
client et d'un no de transaction (ou une date/heure au millième) et ensuite
faire un HLitRechercheDernier() (qui donnerait un accès direct à tout coup)
mais si je peux éviter...
Est-ce bien la seule façon possible ou si je me complique la vie pour rien?
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
patrice
Real Phil a écrit :
Bonjour,
Un fichier d'une application qui contient entre-autre un Code de client et un Solde par Client doit absolument conserver sa séquence chronologique. Avant le prochain ajout, le dernier solde d'un client précis est récupéré et on continue l'ajout de nouvelles transactions pour ce client.
Ce fichier sera "nettoyé" à l'occasion - c'est à dire que des enregistrements seront supprimés par blocs laissant de gros "trous" dans le fichier (qui seront automatiquement "bouchés" éventuellement par la réindexation ou par HAjoute()).
Quand je travaillais avec les fichiers .Dbf il n'y avait aucun problème puisque les ajouts se faisaient toujours physiquement un après l'autre (les enregistrements supprimés n'étaient que "marqués" comme tel). Mais Windev a une gestion intégrée des enregistrements vides qui sont remplis à chaque HAjoute - ce qui fait que les enregistrements ajoutés peuvent se retrouver n'importe où dans le fichier - et un HLitRechercheDernier() lit le dernier enregistrement physique... qui n'est pas nécessairement le dernier enregistrement pour un client précis.
Pour récupérer le dernier Solde d'un client j'ai donc conclut que je devais ajouter une rubrique Identifiant automatique (une clef unique par concept). J'ai fait quelques tests avec le code suivant;
HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient) HChangeClé(MonFichier,IDAuto,hRespecteFiltre) HLitDernier(MonFichier) SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON mDernierSolde=0.00 HDésactiveFiltre(MonFichier)
Ça semble bien fonctionner de cette façon mais j'aimerais l'avis de personnes plus expérimentées. Il me semble que ça fait beaucoup de code pour juste aller chercher une simple information. Et je veux être certain que ça va bien fonctionner avec des milliers d'enregistrements.
Je présume que je pourrais aussi avoir une rubrique composée du Code du client et d'un no de transaction (ou une date/heure au millième) et ensuite faire un HLitRechercheDernier() (qui donnerait un accès direct à tout coup) mais si je peux éviter...
je vois pas la différence entre ce dernier paragraphe et la premiere méthode.
1iere méthode: - limiter la recherche à codeclient=x - lire le plus haut id 2ieme méthode: - chercher le plus haut id du client x
ca fait un peu kif kif , non ? sauf que la deuxieme méthode,(comme précisé) est un accés, pas direct, mais via une clé, ce qui beaucoup plus rapide que la premiere méhode. (sauf si : - la clé composé client,id existe - windev optimise son job - les stats sont calculés régulierement )
Est-ce bien la seule façon possible ou si je me complique la vie pour rien?
Votre expérience serait appréciée.
Réal Phil
moi dans ce cas, - si les enregistrement ne bouge pas trop: un fichier client suplémentaire ne contenant que la fameuse valeur - si ca bouge, alors ajouter la date/heure
Real Phil a écrit :
Bonjour,
Un fichier d'une application qui contient entre-autre un Code de client et
un Solde par Client doit absolument conserver sa séquence chronologique.
Avant le prochain ajout, le dernier solde d'un client précis est récupéré et
on continue l'ajout de nouvelles transactions pour ce client.
Ce fichier sera "nettoyé" à l'occasion - c'est à dire que des
enregistrements seront supprimés par blocs laissant de gros "trous" dans le
fichier (qui seront automatiquement "bouchés" éventuellement par la
réindexation ou par HAjoute()).
Quand je travaillais avec les fichiers .Dbf il n'y avait aucun problème
puisque les ajouts se faisaient toujours physiquement un après l'autre (les
enregistrements supprimés n'étaient que "marqués" comme tel). Mais Windev a
une gestion intégrée des enregistrements vides qui sont remplis à chaque
HAjoute - ce qui fait que les enregistrements ajoutés peuvent se retrouver
n'importe où dans le fichier - et un HLitRechercheDernier() lit le dernier
enregistrement physique... qui n'est pas nécessairement le dernier
enregistrement pour un client précis.
Pour récupérer le dernier Solde d'un client j'ai donc conclut que je devais
ajouter une rubrique Identifiant automatique (une clef unique par concept).
J'ai fait quelques tests avec le code suivant;
HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient)
HChangeClé(MonFichier,IDAuto,hRespecteFiltre)
HLitDernier(MonFichier)
SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON
mDernierSolde=0.00
HDésactiveFiltre(MonFichier)
Ça semble bien fonctionner de cette façon mais j'aimerais l'avis de
personnes plus expérimentées. Il me semble que ça fait beaucoup de code pour
juste aller chercher une simple information. Et je veux être certain que ça
va bien fonctionner avec des milliers d'enregistrements.
Je présume que je pourrais aussi avoir une rubrique composée du Code du
client et d'un no de transaction (ou une date/heure au millième) et ensuite
faire un HLitRechercheDernier() (qui donnerait un accès direct à tout coup)
mais si je peux éviter...
je vois pas la différence entre ce dernier paragraphe et la premiere
méthode.
1iere méthode:
- limiter la recherche à codeclient=x
- lire le plus haut id
2ieme méthode:
- chercher le plus haut id du client x
ca fait un peu kif kif , non ?
sauf que la deuxieme méthode,(comme précisé) est un accés, pas direct,
mais via une clé, ce qui beaucoup plus rapide que la premiere méhode.
(sauf si :
- la clé composé client,id existe
- windev optimise son job
- les stats sont calculés régulierement
)
Est-ce bien la seule façon possible ou si je me complique la vie pour rien?
Votre expérience serait appréciée.
Réal Phil
moi dans ce cas,
- si les enregistrement ne bouge pas trop: un fichier client
suplémentaire ne contenant que la fameuse valeur
- si ca bouge, alors ajouter la date/heure
Un fichier d'une application qui contient entre-autre un Code de client et un Solde par Client doit absolument conserver sa séquence chronologique. Avant le prochain ajout, le dernier solde d'un client précis est récupéré et on continue l'ajout de nouvelles transactions pour ce client.
Ce fichier sera "nettoyé" à l'occasion - c'est à dire que des enregistrements seront supprimés par blocs laissant de gros "trous" dans le fichier (qui seront automatiquement "bouchés" éventuellement par la réindexation ou par HAjoute()).
Quand je travaillais avec les fichiers .Dbf il n'y avait aucun problème puisque les ajouts se faisaient toujours physiquement un après l'autre (les enregistrements supprimés n'étaient que "marqués" comme tel). Mais Windev a une gestion intégrée des enregistrements vides qui sont remplis à chaque HAjoute - ce qui fait que les enregistrements ajoutés peuvent se retrouver n'importe où dans le fichier - et un HLitRechercheDernier() lit le dernier enregistrement physique... qui n'est pas nécessairement le dernier enregistrement pour un client précis.
Pour récupérer le dernier Solde d'un client j'ai donc conclut que je devais ajouter une rubrique Identifiant automatique (une clef unique par concept). J'ai fait quelques tests avec le code suivant;
HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient) HChangeClé(MonFichier,IDAuto,hRespecteFiltre) HLitDernier(MonFichier) SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON mDernierSolde=0.00 HDésactiveFiltre(MonFichier)
Ça semble bien fonctionner de cette façon mais j'aimerais l'avis de personnes plus expérimentées. Il me semble que ça fait beaucoup de code pour juste aller chercher une simple information. Et je veux être certain que ça va bien fonctionner avec des milliers d'enregistrements.
Je présume que je pourrais aussi avoir une rubrique composée du Code du client et d'un no de transaction (ou une date/heure au millième) et ensuite faire un HLitRechercheDernier() (qui donnerait un accès direct à tout coup) mais si je peux éviter...
je vois pas la différence entre ce dernier paragraphe et la premiere méthode.
1iere méthode: - limiter la recherche à codeclient=x - lire le plus haut id 2ieme méthode: - chercher le plus haut id du client x
ca fait un peu kif kif , non ? sauf que la deuxieme méthode,(comme précisé) est un accés, pas direct, mais via une clé, ce qui beaucoup plus rapide que la premiere méhode. (sauf si : - la clé composé client,id existe - windev optimise son job - les stats sont calculés régulierement )
Est-ce bien la seule façon possible ou si je me complique la vie pour rien?
Votre expérience serait appréciée.
Réal Phil
moi dans ce cas, - si les enregistrement ne bouge pas trop: un fichier client suplémentaire ne contenant que la fameuse valeur - si ca bouge, alors ajouter la date/heure
Real Phil
> > HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient) > HChangeClé(MonFichier,IDAuto,hRespecteFiltre) > HLitDernier(MonFichier) > SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON > mDernierSolde=0.00 > HDésactiveFiltre(MonFichier) > > Je présume que je pourrais aussi avoir une rubrique composée du Code du > client et d'un no de transaction (ou une date/heure au millième) et
ensuite
> faire un HLitRechercheDernier() (qui donnerait un accès direct à tout
coup)
> mais si je peux éviter...
je vois pas la différence entre ce dernier paragraphe et la premiere méthode.
1iere méthode: - limiter la recherche à codeclient=x - lire le plus haut id 2ieme méthode: - chercher le plus haut id du client x
ca fait un peu kif kif , non ?
Je ne trouve pas... je vois 4 lignes de code ci-dessous...
1. HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient) 2. HChangeClé(MonFichier,IDAuto,hRespecteFiltre) 3. HLitDernier(MonFichier) SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON mDernierSolde=0.00 4. HDésactiveFiltre(MonFichier)
...contre une seule avec HLitRechercheDernier()
moi dans ce cas, - si les enregistrement ne bouge pas trop: un fichier client suplémentaire ne contenant que la fameuse valeur - si ca bouge, alors ajouter la date/heure
Ah bon, alternative possible que je n'avais pas envisagée. Je vais y considérer.
Merci pour la réponse.
> > HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient)
> HChangeClé(MonFichier,IDAuto,hRespecteFiltre)
> HLitDernier(MonFichier)
> SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON
> mDernierSolde=0.00
> HDésactiveFiltre(MonFichier)
>
> Je présume que je pourrais aussi avoir une rubrique composée du Code du
> client et d'un no de transaction (ou une date/heure au millième) et
ensuite
> faire un HLitRechercheDernier() (qui donnerait un accès direct à tout
coup)
> mais si je peux éviter...
je vois pas la différence entre ce dernier paragraphe et la premiere
méthode.
1iere méthode:
- limiter la recherche à codeclient=x
- lire le plus haut id
2ieme méthode:
- chercher le plus haut id du client x
ca fait un peu kif kif , non ?
Je ne trouve pas... je vois 4 lignes de code ci-dessous...
1. HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient)
2. HChangeClé(MonFichier,IDAuto,hRespecteFiltre)
3. HLitDernier(MonFichier)
SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON
mDernierSolde=0.00
4. HDésactiveFiltre(MonFichier)
...contre une seule avec HLitRechercheDernier()
moi dans ce cas,
- si les enregistrement ne bouge pas trop: un fichier client
suplémentaire ne contenant que la fameuse valeur
- si ca bouge, alors ajouter la date/heure
Ah bon, alternative possible que je n'avais pas envisagée. Je vais y
considérer.
> > HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient) > HChangeClé(MonFichier,IDAuto,hRespecteFiltre) > HLitDernier(MonFichier) > SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON > mDernierSolde=0.00 > HDésactiveFiltre(MonFichier) > > Je présume que je pourrais aussi avoir une rubrique composée du Code du > client et d'un no de transaction (ou une date/heure au millième) et
ensuite
> faire un HLitRechercheDernier() (qui donnerait un accès direct à tout
coup)
> mais si je peux éviter...
je vois pas la différence entre ce dernier paragraphe et la premiere méthode.
1iere méthode: - limiter la recherche à codeclient=x - lire le plus haut id 2ieme méthode: - chercher le plus haut id du client x
ca fait un peu kif kif , non ?
Je ne trouve pas... je vois 4 lignes de code ci-dessous...
1. HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient) 2. HChangeClé(MonFichier,IDAuto,hRespecteFiltre) 3. HLitDernier(MonFichier) SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON mDernierSolde=0.00 4. HDésactiveFiltre(MonFichier)
...contre une seule avec HLitRechercheDernier()
moi dans ce cas, - si les enregistrement ne bouge pas trop: un fichier client suplémentaire ne contenant que la fameuse valeur - si ca bouge, alors ajouter la date/heure
Ah bon, alternative possible que je n'avais pas envisagée. Je vais y considérer.
Pour les intéressés, pour que le code ci-dessus fonctionne bien il faut absolument ajouter hRespecteFiltre comme option à HLitDernier(). La commande à utiliser est donc HLitDernier(MonFichier,hRespecteFiltre)
Pour les intéressés, pour que le code ci-dessus fonctionne bien il faut
absolument ajouter hRespecteFiltre comme option à HLitDernier(). La commande
à utiliser est donc HLitDernier(MonFichier,hRespecteFiltre)
Pour les intéressés, pour que le code ci-dessus fonctionne bien il faut absolument ajouter hRespecteFiltre comme option à HLitDernier(). La commande à utiliser est donc HLitDernier(MonFichier,hRespecteFiltre)
Réal Phil
patrice
"Real Phil" a écrit dans le message de news:aN8Yh.27662$
Je ne trouve pas... je vois 4 lignes de code ci-dessous...
1. HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient) 2. HChangeClé(MonFichier,IDAuto,hRespecteFiltre) 3. HLitDernier(MonFichier) SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON mDernierSolde=0.00 4. HDésactiveFiltre(MonFichier)
...contre une seule avec HLitRechercheDernier()
ce n'est pas le nombre de ligne qui compte, mais le nombre d'accès disque. si on ne regarde que les acces disque, on se retrouve avec un HlitDernier pour le 1/ contre un HlitRechercheDernier pour le 2/ Conclusion: la seule différence entre les 2 méthodes et que la 2/ nécessite un index . et si tu ajoute un index, tu peux aussi l'utiliser pour la 1/ ....
"Real Phil" <_pasde_Spam_realp@ultra.ca> a écrit dans le message de
news:aN8Yh.27662$sy3.87728@wagner.videotron.net...
Je ne trouve pas... je vois 4 lignes de code ci-dessous...
1. HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient)
2. HChangeClé(MonFichier,IDAuto,hRespecteFiltre)
3. HLitDernier(MonFichier)
SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON
mDernierSolde=0.00
4. HDésactiveFiltre(MonFichier)
...contre une seule avec HLitRechercheDernier()
ce n'est pas le nombre de ligne qui compte, mais le nombre d'accès disque.
si on ne regarde que les acces disque, on se retrouve avec un HlitDernier
pour le 1/ contre un HlitRechercheDernier pour le 2/
Conclusion: la seule différence entre les 2 méthodes et que la 2/ nécessite
un index .
et si tu ajoute un index, tu peux aussi l'utiliser pour la 1/ ....
"Real Phil" a écrit dans le message de news:aN8Yh.27662$
Je ne trouve pas... je vois 4 lignes de code ci-dessous...
1. HFiltreIdentique(MonFichier,MaRubriqueCodeClient,sCodeDuClient) 2. HChangeClé(MonFichier,IDAuto,hRespecteFiltre) 3. HLitDernier(MonFichier) SI HTrouve() ALORS mDernierSolde=MonFichier.SoldePayable SINON mDernierSolde=0.00 4. HDésactiveFiltre(MonFichier)
...contre une seule avec HLitRechercheDernier()
ce n'est pas le nombre de ligne qui compte, mais le nombre d'accès disque. si on ne regarde que les acces disque, on se retrouve avec un HlitDernier pour le 1/ contre un HlitRechercheDernier pour le 2/ Conclusion: la seule différence entre les 2 méthodes et que la 2/ nécessite un index . et si tu ajoute un index, tu peux aussi l'utiliser pour la 1/ ....
