PcSoft: nouvelle trouvaille coupe-souffle

farplus wrote:

Bonjour à tous,

Voici une nouvelle trouvaille toute chaude du ST de PcSoft:
Acte I
je signale - avec explications claires - le nième bug sur table, bien
entendu 1ère réponse: nous n'avons pas compris...

Acte II
envoie d'un mode opératoire hypercomplet

Réponse:
Le Support Technique ne peut pas prendre en charge la mise au point d'un
code.

Avouez que c'est bien torché non ?

PS: pour ce qui aimeraient comprendre voici le pb:

fichier HF, 2 rubriques, A1 (entier, clé unique) A2 (chaine).

Fenêtre avec table créée avec assistant liée au fichier.

Adjonction d'une colonne B1 (entier) dans la table.

Par programmation (bouton ou autre) affectation d'une valeur au champ B1
sélectionné par le bandeau., fonction contrôlée réussie.

Lorsqu'on reselecte la ligne, B1 est réinitialisé.

Clair n'est-ce pas ?

J'attends vos sentiments et/ou critiques.



A+

oui oui

les tables fichiers ne sont pas faites pour êtres complétées avec des
données mémoires sauf si on prend la meine de les calculer à chaque
affichage de ligne. il vaut donc mieux éviter d'y avoir de lourds calculs.

une solution et d'utiliser
- des IDauto dans TOUS les fichiers de l'analyse : ils sont utilisé
précisément dans ce cas mais aussi pour palier au pb du manque de
hNumEnr en SQL

- un fichier FIC décrit en dynamique comme suit
IDFic : id auto de FIC (ras)
IFFICHIER : id auto de FICHIER (pour relation)
CHPCOLONNE : Champ qui sera ajouté à la colonne de table fichier

ajouter la colonne et le faire pointer sur cFIC.CHPCOLONNE via la
relation FICHIER.IDFICHIER->FIC.IDFICHIER
L'affectation est possible via les propriété des tables :
..rubriqueaffichée

consulter l'aide pour finaliser la relation entre la table et les fichier.

pour les traitments vous pouvez ensuite utiliser vos deux fichiers
FICHIER et FIC
FIC comporte alors vos données 'temporaires'

NB : cette méthode est un peu technique mais térriblement efficace vu la
différence entre les tables fichiers et les tables mémoires.

Enfin, en cas de problème me passer un mail pour compléments

@+ R&B

Bonjour RB

tu écris:

oui oui

les tables fichiers ne sont pas faites pour êtres >complétées avec des

données mémoires

première nouvelle.
tu te réfères à quelle information (aide en ligne, papier ou autre) ?

Même si c'est vrai, PcSoft aurait pû me le signaler...
A+

farplus wrote:

Bonjour RB

tu écris:

oui oui

les tables fichiers ne sont pas faites pour êtres >complétées avec des

données mémoires

première nouvelle.
tu te réfères à quelle information (aide en ligne, papier ou autre) ?

Même si c'est vrai, PcSoft aurait pû me le signaler...
A+

Bonjour farplus,
Heureuse nouvelle alors.
Je me réfère simplement à ma modique expérience et évidement mes propos
n'engagent que moi, j'assume sans problème. Quand je produit une
coquille, je sais réagir. Dans le cas contraire je me permet de citer
mes sources en général.
Si mon propos a été trop directif, je m'en excuses mais il s'agit
simplement de mettre les gens dans le bonne voie en évitant les mélanges
de genres qui peuvent conduire à des perte de performances ou a des
traitement difficile à réaliser...
Attention, pas de mégalomanie pour autant, on apprend tous les jours...

Techniquement je tiens cette affirmation sur la base que les tables
fichiers sont traitées par bloc (les lignes affichées, c'est la
navigation dans la table qui déplace le pointeur de lecture et donc
déplace le bloc d'enregistrements 'actifs' dans la table) quand les
infos mémoires le sont sur toute la table.
En clair dans une tables fichier, sont 'en mémoire' les seule lignes
affichée. Dans une table (colonne) mémoire, toute la table est en
mémoire. Cela explique au passage la différence de performance dans les
volumes important.
Cette différence a pour conséquence le besoin de recalculer les colonnes
mémoire à chaque affichage des lignes. sinon, lorsque la ligne sort de
la table, la valeur est perdue. Voila ce que j'en ai compris/lu, je veux
bien recevoir le dossier complet sur la face cachée des tables windev si
je me trompe.
J'espère avoir été clair sinon merci de me contacter soit en direct soit
sur le forum de mon site ou par mp (messages personnels ftoujours au
même endroit).

D'autre part si la solution proposée ne convient pas, tant pis.
L'objet de cette participation à ce NG était simple : proposer une
solution à laquelle on ne pense pas toujours mais qui marche trés bien.


Windev 7x permet aussi de faire de nombreuses choses en dynamique sur
les fichier qui permettent de pallier à la lenteur des même traitement
avec des objets mémoire (tables, structures...), c'est d'ailleur un des
grand apport de 7x sur 5, evidément toujours selon moi.

Quand à la doc PCSoft ou le ST, je ne m'engage pas pour eux et
réciproquement.

Bonne journée et bonnes tables,
R&B

> Bonjour farplus,
Heureuse nouvelle alors.
Je me réfère simplement à ma modique expérience et évidement mes propos
n'engagent que moi, j'assume sans problème. Quand je produit une
coquille, je sais réagir. Dans le cas contraire je me permet de citer
mes sources en général.
Si mon propos a été trop directif, je m'en excuses mais il s'agit
simplement de mettre les gens dans le bonne voie en évitant les mélanges
de genres qui peuvent conduire à des perte de performances ou a des
traitement difficile à réaliser...
Attention, pas de mégalomanie pour autant, on apprend tous les jours...

Techniquement je tiens cette affirmation sur la base que les tables
fichiers sont traitées par bloc (les lignes affichées, c'est la
navigation dans la table qui déplace le pointeur de lecture et donc
déplace le bloc d'enregistrements 'actifs' dans la table) quand les
infos mémoires le sont sur toute la table.
En clair dans une tables fichier, sont 'en mémoire' les seule lignes
affichée. Dans une table (colonne) mémoire, toute la table est en
mémoire. Cela explique au passage la différence de performance dans les
volumes important.
Cette différence a pour conséquence le besoin de recalculer les colonnes
mémoire à chaque affichage des lignes. sinon, lorsque la ligne sort de
la table, la valeur est perdue. Voila ce que j'en ai compris/lu, je veux
bien recevoir le dossier complet sur la face cachée des tables windev si
je me trompe.
J'espère avoir été clair sinon merci de me contacter soit en direct soit
sur le forum de mon site ou par mp (messages personnels ftoujours au
même endroit).

D'autre part si la solution proposée ne convient pas, tant pis.
L'objet de cette participation à ce NG était simple : proposer une
solution à laquelle on ne pense pas toujours mais qui marche trés bien.


Windev 7x permet aussi de faire de nombreuses choses en dynamique sur
les fichier qui permettent de pallier à la lenteur des même traitement
avec des objets mémoire (tables, structures...), c'est d'ailleur un des
grand apport de 7x sur 5, evidément toujours selon moi.

Quand à la doc PCSoft ou le ST, je ne m'engage pas pour eux et
réciproquement.

Bonne journée et bonnes tables,
R&B

Bonjour,

Je confirme, les tables fichiers sont plus rapides et saturent moins que les
tables mémoire, surtout pour des volumes importants de données.

Et l'aide en ligne le confirme également :
<<
Table Mémoire
Remplit une table mémoire avec tous les enregistrements d'un fichier, d'une
vue Hyper File 7 ou d'une requête (requête créée avec l'éditeur de requêtes,
ou avec la fonction HExécuteRequêteSQL). La table est vidée, puis remplie
avec le contenu du fichier ou de la requête.
ATTENTION : cette opération peut être très longue et saturer la mémoire si
le fichier est volumineux.

Table Fichier
Le nombre d'enregistrement pouvant être visualisés est illimité, seules les
lignes visibles de la table sont chargées en mémoire.

Et je confirme d'autant plus, que quelques développeurs m'ayant questionnés
sur la lenteur (et parfois à la limite complète de la saturation de
l'affichage) de certains traitements dans leurs appli, après avoir examiné
leur code, je me suis rendu compte qu'il pratiquaient une utilisation
intensive des tables mémoires (et cela sur de gros fichiers), leur
remplacement par des tables fichiers a résolu le problème de manière
spectaculaire, des traitements qui demandaient plusieurs secondes sont
devenus instantanés.

Ceci explique aussi peut être pourquoi je n'ai pas de problèmes spécifiques
sur des applis avec fichiers HF en réseau, en plus de l'utilisation de
Hfiltre qui s'est avéré être plus rapide que les requetes.

Sincères salutations
--
Jean-Claude FLAJOULOT
Sécurité, Pointage & Biométrie
SPetB_no.spam@wanadoo.fr

enlever _no.spam pour me contacter en PV.

SP&B wrote:

Bonjour,

Bonjour SP, le &B ne signifie pas de parenté 8-D

Je confirme, les tables fichiers sont plus rapides et saturent moins que les
tables mémoire, surtout pour des volumes importants de données.

[...]
Ouf ! j'ai bien cru que mes travaux de recherche sur le sujet pour
arriver a obtenir des réponses correcte même sur des infrastructures
moyennes et surtout que les résultats en production n'étaient qu'un
rève.... Je suis soulagé.

Si kekun se sent de produire un dossier ficelé sur le truc, je connais
un endroit où le poser...

Ainsi cela pourra servir à combler un manque de netteté et a faire
progresser les choses.

@+ R&B
Animateur de rbesset.net : portail windev

Bonjour à tous,

que les tables fichiers utilisent moins de mémoire c'est une affaire
entendue, qu'elles fassent une relecture à chaque affichage c'est plus que
OK.
Mais, dès qu'on ajoute un rubrique non liée au fichier, la table devrait se
comporter comme une table mémoire qui mémorise les données des colonnes
"orphelines" et l'identificateur de l'enregistrement fichier relié pour la
relecture.
Ce n'est pas plus sorcier que cela.

Mais le but de mon poste n'était pas de trouver une solution à un pb, juste
de fustiger une réponse cavalière de notre éditeur préféré (!?).

A+
"R&B" <info@_pasdespam_rbesset.net> a écrit dans le message de
news:bl0q0l$b6n$1@s1.read.news.oleane.net...

farplus wrote:
> Bonjour RB
>
> tu écris:
>
>>oui oui
>>
>>les tables fichiers ne sont pas faites pour êtres >complétées avec des
>
> données mémoires
>
> première nouvelle.
> tu te réfères à quelle information (aide en ligne, papier ou autre) ?
>
> Même si c'est vrai, PcSoft aurait pû me le signaler...
> A+
>
>
Bonjour farplus,
Heureuse nouvelle alors.
Je me réfère simplement à ma modique expérience et évidement mes propos
n'engagent que moi, j'assume sans problème. Quand je produit une
coquille, je sais réagir. Dans le cas contraire je me permet de citer
mes sources en général.
Si mon propos a été trop directif, je m'en excuses mais il s'agit
simplement de mettre les gens dans le bonne voie en évitant les mélanges
de genres qui peuvent conduire à des perte de performances ou a des
traitement difficile à réaliser...
Attention, pas de mégalomanie pour autant, on apprend tous les jours...

Techniquement je tiens cette affirmation sur la base que les tables
fichiers sont traitées par bloc (les lignes affichées, c'est la
navigation dans la table qui déplace le pointeur de lecture et donc
déplace le bloc d'enregistrements 'actifs' dans la table) quand les
infos mémoires le sont sur toute la table.
En clair dans une tables fichier, sont 'en mémoire' les seule lignes
affichée. Dans une table (colonne) mémoire, toute la table est en
mémoire. Cela explique au passage la différence de performance dans les
volumes important.
Cette différence a pour conséquence le besoin de recalculer les colonnes
mémoire à chaque affichage des lignes. sinon, lorsque la ligne sort de
la table, la valeur est perdue. Voila ce que j'en ai compris/lu, je veux
bien recevoir le dossier complet sur la face cachée des tables windev si
je me trompe.
J'espère avoir été clair sinon merci de me contacter soit en direct soit
sur le forum de mon site ou par mp (messages personnels ftoujours au
même endroit).

D'autre part si la solution proposée ne convient pas, tant pis.
L'objet de cette participation à ce NG était simple : proposer une
solution à laquelle on ne pense pas toujours mais qui marche trés bien.


Windev 7x permet aussi de faire de nombreuses choses en dynamique sur
les fichier qui permettent de pallier à la lenteur des même traitement
avec des objets mémoire (tables, structures...), c'est d'ailleur un des
grand apport de 7x sur 5, evidément toujours selon moi.

Quand à la doc PCSoft ou le ST, je ne m'engage pas pour eux et
réciproquement.

Bonne journée et bonnes tables,
R&B

Bonsoir,

Bonjour SP, le &B ne signifie pas de parenté 8-D

Non le &B n'a aucun lien de parenté, à moins que vous ne appeliez Biométrie
(:- et dans ce cas on fera une recherche généalogique (:-
quand au & c'est pour et, mais mis sous cette forme en raison d'une part du
coté estéthique du caracatère et d'autre d'un partenariat que j'ai avec
France Telecom au niveau Transveil.

Si kekun se sent de produire un dossier ficelé sur le truc, je connais
un endroit où le poser...

Ainsi cela pourra servir à combler un manque de netteté et a faire
progresser les choses.

Ce que vous dites est absolument vrai, mais faire un dossier complet prend
du temps, et c'est ce qui me manque le plus, mais l'idée est bonne, a suivre
donc...

Sincères salutations
--
Jean-Claude FLAJOULOT
Sécurité, Pointage & Biométrie
SPetB_no.spam@wanadoo.fr

enlever _no.spam pour me contacter en PV.