Discussion :

[ecoinfo]

Pour le développement d’une application de gestion commerciale, mon fichier article est de plus de 10000 enregistrements, pour créer un BL, j’ouvre une fenêtre et je remplir le client, la date etc.
Puis en bas j’ai met une table Ligne BL avec des buttons à gauches.
Exemple le bouton Ajouter, ouvre la fenêtre liste des articles avec ses 6000 enregistrements, je sélectionner l’article et je valider et la fenêtre se ferme et l’article est ajouter sur Lignes BL, je répète la même opération pour tous les articles du bl.
Le problème est dans le temps de remplissage de ma table article, avec ces différents appels.
Pour faire un bl avec 5 articles, il faut ouvrir la fenêtre 5 fois, exécuter la requête 5 fois etc.
J’exécute ma requête avec hexécuterequêtesql et je rempli avec
pour tout maRequette
tableajouteligne(….)
fin
Le remplissage prend 4 sec et plus
La table article de la fenêtre article est une table mémoire avec 12 colonnes. J’ai met La procédure du remplissage dans l’initialisation de la fenêtre ?

Est-ce que c’est le bon endroit ?
Existe-t –elle une autre manière de faire ce scenario.?


Merci d'avance

[tatayo]

Bonjour,
6000 articles, ce n'est pas énorme, mais je pense tout de même qu'il n'est pas utile de remplir systématiquement la table.
Voici ce que je ferai:
1. Une saisie directe dans la table des lignes du BL, avec une recherche sur le code article, puis sur le code barre (douchette...).
2. Un bouton de recherche, qui propose des critères de recherche (code, désignation...) et un remplissage de la table à la demande, en fonction des critères.

C'est ce qu'on fait sur toutes nos applications, et dans 99% des cas l'utilisateur sait de quel article il a besoin, donc tape le code article directement, sans passer par la recherche des articles.

D'autres pistes:
Tu dis que tu utilises une table mémoire, remplie "à la main" à partir d'une requête. Pourquoi ne pas utiliser une table fichier ?
Tu ouvres la fenêtre à chaque saisie d'un article, charge à chaque fois la table... Pourquoi ne pas garder la fenêtre ouverte (ouvresoeur) et soit la garder à l'écran, soit la basculer visible/invisible. Ainsi l'affichage serait instantanné.

Tatayo.

[ecoinfo]

Bonjour

D'autres pistes:
Tu dis que tu utilises une table mémoire, remplie "à la main" à partir d'une requête. Pourquoi ne pas utiliser une table fichier ?
Tu ouvres la fenêtre à chaque saisie d'un article, charge à chaque fois la table... Pourquoi ne pas garder la fenêtre ouverte (ouvresoeur) et soit la garder à l'écran, soit la basculer visible/invisible. Ainsi l'affichage serait instantanné.

La table fichier est moins fluide, donc j'ai opté pour une table mémoire.
Mais j'ai quelques problèmes

Dans l'initialisation de la fenêtre (ou il y a ma table), j'afficher 30 enregistrement, et au scrolle sur la table il faut que j'afficher mes autres enregistrements.

Mais je n’ai pas le moyenne de savoir est ce que l'utilisateur à scroller en haut au bien en bas?

[tatayo]

La table fichier est moins fluide, donc j'ai opté pour une table mémoire.
Mais j'ai quelques problèmes

C'est étonnant, la table fichier est sensé êtrece qu'il y a de plus fluide...

Dans l'initialisation de la fenêtre (ou il y a ma table), j'afficher 30 enregistrement, et au scrolle sur la table il faut que j'afficher mes autres enregistrements.

Mais je n’ai pas le moyenne de savoir est ce que l'utilisateur à scroller en haut au bien en bas?

En fait, c'est précisément ce que fait une table fichier...

Je pense sincèrement que les utilisateurs ne vont pas chercher un article dans une table de 6000 lignes.
Quand ta base article sera vraiment conséquente (environ 100000 ref dans la notre...), ta méthode deviendra ingérable.
Pourquoi ne pas proposer une saisie directe du code, et une fenêtre de recherche multi-critères ? Ainsi tu ne cherches que les articles qui correspondent aux critères.

Aucune des applications que nous utilisons, qu'elle soit développée en interne ou achetée, n'affiche la liste des articles sans passer par une fenêtre de recherche avant.

Tatayo.

[EDM-TAHITI]

Hello,
D'une part, TATAYO a raison et mille fois raison lorsqu'il dit

Je pense sincèrement que les utilisateurs ne vont pas chercher un article dans une table de 6000 lignes.
Quand ta base article sera vraiment conséquente (environ 100000 ref dans la notre...), ta méthode deviendra ingérable.
Pourquoi ne pas proposer une saisie directe du code, et une fenêtre de recherche multi-critères ? Ainsi tu ne cherches que les articles qui correspondent aux critères.

d'autre part, le sujet a été traité une multitude de fois et une recherche aurait apportée quasiment toutes les réponses à tes questions...

Et tu n'as pas encore abordé la gestion de stocks...

[ecoinfo]

Salut
Je suis totalement d'accord, c'est ce que je viens d'appliquer. MAIS
Voila un autre problème similaire.
Mon fichier bonlivraison : 6000 enregistrements
Sur ma liste des bon de livraison, j'aimerai avoir les dernières enregistrements devant moi, et j'ai à droit les buttons ajouter, modifier qui ouvrent une autre fenêtre (Lignes bl).
Donc l'idéal que je voix est d'afficher les 30 dernières, et au scrolle sur la table, et la ou mon problème, je dois afficher au fur et à mesure les autres enregistrements.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
TableSupprimeTout(TableEntete)
sql est une chaîne
 
sql="SELECT COUNT(*) as nb FROM BonSortie_M "+Fil_Sortie+""
HExécuteRequêteSQL(Req_Sortie,hRequêteDéfaut,sql)
HLitPremier(Req_Sortie)
SI Req_Sortie.nb>30 ALORS
	var1=Req_Sortie.nb-30
	var2=30
SINON
	var1=0
	var2=30
FIN
 
sql="SELECT  BonSortie_M.nbs AS nbs, BonSortie_M.date AS DATE, BonSortie_M.CodeUser, BonSortie_M.MLE AS MLE, BonSortie_M.valide AS valide  FROM BonSortie_M     "+Fil_Sortie+"  ORDER BY nbs ASC LIMIT  "+var1+", "+var2+""
HExécuteRequêteSQL(Req_Sortie,hRequêteDéfaut,sql)
 
 
POUR TOUTE Req_Sortie 
	TableAjouteLigne(TableEntete,Req_Sortie.nbs,Req_Sortie.date,Req_Sortie.CodeUser,Req_Sortie.MLE,Req_Sortie.MLE,Req_Sortie.valide)
FIN

Merci d'avance.

[ecoinfo]

j'aimerai faire comme table fichier, mais sur une table mémoire..

par exemple à l'ouverture de la fenêtre j'aimerai avoir sur la table lisible devant moi les 30 dernières par exemple..

merci d'avance

[tatayo]

A priori tu vas chercher les BL par date, en prenant les dernier.
Dans ce cas tu pêux t'en sortir ainsi:
Dans le code d'affichage d'une ligne de la table, si l'indice est le dernier de la table, tu vas chercher les BL suivant.
Pour ce faire, tu peux utiliser une requête de ce genre:

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
select top 30 *
from  BL
where BL.datecreation <= '%1' and bl.id <> '%2'
order by BL.datecreation desc

%1 représente la date du BL de la dernière ligne de la table.
%2 représente l'Id du dernier BL (pour ne pas le récupérer à chaque fois
Ainsi à chaque fois que tu attends la dernière ligne, tu vas chercher les 30 BL les plus récents ayant une date <= à celle du dernier que tu as récupéré, en ignorant ce dernier BL.
Tu n'as alors plus qu'à ajouter les BL dans la table.

J'espère juste que tu as un index sur cette colonne, sinon les performances risquent d'en souffrir.

Tatayo.

[ecoinfo]

salut

je comprend pas pourquoi le traitement affichage d'une ligne s'execute une seul fois !

Code d'initialisation de la table

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
TableSupprimeTout(TableEntete)
sql est une chaîne
sql="SELECT top 1  BonSortie_M.nbs AS nbs  FROM BonSortie_M     ORDER BY nbs DESC "
HExécuteRequêteSQL(Req_Sortie,hRequêteDéfaut,sql)
POUR TOUTE Req_Sortie sur nbs
	TableAjouteLigne(TableEntete,Req_Sortie.nbs)
FIN

Code d'affichage d'une ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
sql est une chaîne
sql="SELECT TOP 30  BonSortie_M.nbs AS nbs  FROM BonSortie_M where      BonSortie_M.nbs >"+TableEntete.COL_N_bon+"  ORDER BY nbs DESC"
HExécuteRequêteSQL(Req_Sortie,hRequêteDéfaut,sql)
POUR TOUTE Req_Sortie sur nbs
	TableAjouteLigne(TableEntete,Req_Sortie.nbs)
FIN

[tatayo]

Je vois un gros problème:
Dans l'init, tu ajoutes une ligne.
L'ajout de la ligne déclenche l'affichage de celle-ci.
L'affichage de la ligne lance LA MEME REQUETE
Dans l'affichage de la ligne, tu ajoutes une ligne, ce qui lance l'affichage de celle-ci.

Je pense que c'est ce bouclage qui gène Windev.

Je ferai ceci:
L'ajout de ligne ne doit se faire que dans le code d'affichage de la dernière ligne.
Dans l'init, il faut geler l'affichage de la table.
Dans le code d'affichage de la ligne, il faut aussi geler l'affichage de la table.

Tatayo.

[ecoinfo]

pouvez-vous m'expliquer, car j'ai pas l'evenement de l'ajout de la dernière ligne sur la table en windev !!

[Guardian]

pouvez-vous m'expliquer, car j'ai pas l'evenement de l'ajout de la dernière ligne sur la table en windev !!

L'ajout de ligne ne doit se faire que dans le code d'affichage de la dernière ligne..

Faut lire aussi