Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

WD12 - MySQL, Table fichier

8 réponses
Avatar
I.G.LOG
Bonjour,
J'ai développé une classe qui émule un parcours de table (émulation de table
fichier). Le principe est simple:
En gros, je passe en paramètre la requete et j'affiche les x premiers
résultats (avec limit 0,x). A chaque affichage, je mémorise la valeur de clé
de la 1ere ligne affichée ainsi que la dernière. Dans le cas d'un
déplacement vers le bas, je relis à partir de la dernière valeur, vers le
haut je lis les x lignes avant la première valeur. Hormis quelques
imperfections, cette classe fonctionne bien...
Sauf, me direz-vous, dans le cas où la valeur de la 1ere ligne = valeur de
la dernière !! C'est bien le problème.
Bien sûr, ce cas n'arrive pas souvent, mais il arrive. Notamment dans cet
exemple: je parcours une table article selon la désignation.
Malheureusement, il y a un grand nombre d'articles qui peuvent avoir la même
désignation. Quand ça arrive, le défilement n'est plus possible.
Si le problème peut éventuellement se régler assez facilement vers le bas
(en incrémentant le limit tel que limit x + 1,y), c'est beaucoup plus
difficile vers le haut !
Voyez vous une astuce qui me permettrait de gérer ce cas, sachant que je
suis sur WD12 / MySQL ?
Merci

8 réponses

Avatar
I.G.LOG
Aucun avis ?
En tous cas Windev arrive à le gérer, je ne sais pas comment.
Pour info, j'avais abandonné les tables fichier car la recherche par la
loupe est extrèmement longue (et quelques autres raison)
Est-ce toujours la cas (temps de recherche par la loupe) en WD14 ?
Avatar
Firetox
Bonjour,

en fait il ne faut pas se baser sur la valeur des enreg mais plutot sur la
limte de depart et la limite de fin completement independament des valeurs
(car le order peut intervenir comme un where) ainsi en remontant tu
decremment e l'indice de depart jusqu'a 1 une fois l'indice de depart
trouver et le nombre de ligne a afficher tu as le limit max

donc il faut 2 indice dans ta classe indiceDep et nobLigne
qui peremttent de faire le limit correcte correspondant a ce que tu dois
remonter

ily a un exemple dans SQLManagerX car c''est comme cela qu'est gerer le
SQLXtable avec les methode s SQLXtable, SQLtableAffiche et XTableFereTouche
pour la gestion des touche dans la table (fleches)

Bon dev
@+

Firetox
"I.G.LOG" a écrit dans le message de
news:4b0eaddd$0$935$
Aucun avis ?
En tous cas Windev arrive à le gérer, je ne sais pas comment.
Pour info, j'avais abandonné les tables fichier car la recherche par la
loupe est extrèmement longue (et quelques autres raison)
Est-ce toujours la cas (temps de recherche par la loupe) en WD14 ?



Avatar
I.G.LOG
"Firetox" a écrit dans le message de news:
4b0eaec3$0$14704$
Bonjour,

en fait il ne faut pas se baser sur la valeur des enreg mais plutot sur la
limte de depart et la limite de fin completement independament des valeurs
(car le order peut intervenir comme un where) ainsi en remontant tu
decremment e l'indice de depart jusqu'a 1 une fois l'indice de depart
trouver et le nombre de ligne a afficher tu as le limit max

donc il faut 2 indice dans ta classe indiceDep et nobLigne
qui peremttent de faire le limit correcte correspondant a ce que tu dois
remonter

ily a un exemple dans SQLManagerX car c''est comme cela qu'est gerer le
SQLXtable avec les methode s SQLXtable, SQLtableAffiche et
XTableFereTouche
pour la gestion des touche dans la table (fleches)




Bonjour Firetox,
je ne comprends pas bien. En ce qui me concerne, le limit est toujours de la
forme limit 0,x ou x est le nombre de ligne visible de la table (si la table
fait 25 lignes, je ne lis que 25 tuples). Ca me permet d'utiliser la loupe:
la valeur recherchée se positionne sur le 1er enregistrement satisfaisant à
la recherche et j'affiche ensuite les 25 lignes suivantes, grâce à la
requete select ... where CHAMP = ValeurLoupe limit 0,25.
Avatar
I.G.LOG
> Bonjour Firetox,
je ne comprends pas bien. En ce qui me concerne, le limit est toujours de
la forme limit 0,x ou x est le nombre de ligne visible de la table (si la
table fait 25 lignes, je ne lis que 25 tuples). Ca me permet d'utiliser la
loupe: la valeur recherchée se positionne sur le 1er enregistrement
satisfaisant à la recherche et j'affiche ensuite les 25 lignes suivantes,
grâce à la requete select ... where CHAMP = ValeurLoupe limit 0,25.




pardon, grâce à la requete > select ... where CHAMP >= ValeurLoupe limit 0,25
Avatar
Gilles
I.G.LOG avait énoncé :
Aucun avis ?
En tous cas Windev arrive à le gérer, je ne sais pas comment.
Pour info, j'avais abandonné les tables fichier car la recherche par la loupe
est extrèmement longue (et quelques autres raison)
Est-ce toujours la cas (temps de recherche par la loupe) en WD14 ?



Ca ne changera jamais en table fichier.

Quand tu fais une recherche loupe, la table est retriée pour être
réaffichée.

Perso, j'ai banni depuis longtemps les tables fichiers.

Les tables mémoires sont 100 fois plus souples, on peut trier sur les
colonnes non indexées ou calculées.

Et pour les tables trop volumineuses, il faut utiliser des champs de
recherche et ne charger que des tables filtrées.
Avatar
Firetox
Bonjour,

Bonjour Firetox,
je ne comprends pas bien. En ce qui me concerne, le limit est toujours de
la forme limit 0,x ou x est le nombre de ligne visible de la table (si la
table fait 25 lignes, je ne lis que 25 tuples). Ca me permet d'utiliser la
loupe: la valeur recherchée se positionne sur le 1er enregistrement
satisfaisant à la recherche et j'affiche ensuite les 25 lignes suivantes,
grâce à la requete select ... where CHAMP = ValeurLoupe limit 0,25.



oui jusque la pas de probleme mais si je joue avec l'adscensseur tu fait
bien bouger l'indice de depart (0 ou x) sous mySQL c'est vrai le deuxieme
nombre correspond au nombre de ligne (mais je reagissait avec le cas ou le
deuxieme nombre correspond a la limite)

mais dans ce cas tu ne devrait pas avoir de souci
quand tu descend tu increment le X de 1 ou 25 suivant si c'est une ligne ou
une page
quand tu remonte tu modifie le X jusqu'a 0

le probleme est que tu veux qu'on puisse remonter sur les enreg ne
correspondant pas au filtre car dans ton code de loupe tu fait un filtre ce
qui n'est pas le fonctionnement de la loupe et le probleme est de remonté
apres ou avant les enreg ne correspondant pas au filtre

pour essayer de faire ce que tu as besoin il faut :

un order sur la colonne cliquer pour la loupe
ensuite il faut determine dans les enreg ou se trouve le premier (valeur
de x qui ne sera pas 0) pour faire un select limit 100,25 car c'est la 100
eme ligne qui correspond a ce qui a ete taper dans la loupe
apres le fonctionnement fonctionnera sans probleme avec les limit

donc la vrai question : comment determiner le X qui correspond au 1er
enreg correspondant a ta loupe

je sais si je suis clair
Avatar
I.G.LOG
"Gilles" a écrit dans le message de
news: 4b0ec422$0$29357$
I.G.LOG avait énoncé :
Aucun avis ?
En tous cas Windev arrive à le gérer, je ne sais pas comment.
Pour info, j'avais abandonné les tables fichier car la recherche par la
loupe est extrèmement longue (et quelques autres raison)
Est-ce toujours la cas (temps de recherche par la loupe) en WD14 ?



Ca ne changera jamais en table fichier.

Quand tu fais une recherche loupe, la table est retriée pour être
réaffichée.

Perso, j'ai banni depuis longtemps les tables fichiers.

Les tables mémoires sont 100 fois plus souples, on peut trier sur les
colonnes non indexées ou calculées.

Et pour les tables trop volumineuses, il faut utiliser des champs de
recherche et ne charger que des tables filtrées.





Bonjour,
Oui c'est aussi les raisons pour lesquelles j'avais abandonné les tables
fichiers... et que j'ai développé cette classe qui permet de parcourir une
table, quelque soit le nombre d'enregistrements (dans mon cas je parcours un
fichier article de + de 100.000 références)
Mais j'ai ce soucis avec la navigation par flèches ou ascenseur, l'objet de
ce post
Avatar
I.G.LOG
>
oui jusque la pas de probleme mais si je joue avec l'adscensseur tu fait
bien bouger l'indice de depart (0 ou x) sous mySQL c'est vrai le deuxieme
nombre correspond au nombre de ligne (mais je reagissait avec le cas ou le
deuxieme nombre correspond a la limite)




Bonjour,

et bien non justement ! Avec l'ascenseur, vers le bas je modifie
dynamiquement la requete pour qu'elle devienne
select ... where CHAMP >= DernièreLigne order by CHAMP limit 0,25
Vers le haut
select ... where CHAMP <= PremierLigne order by CHAMP desc limit 0,25

J'ai opté pour cette méthode car l'affichage est beaucoup plus rapide comme
ça (plutôt qu'avec des limit x,25 surtout quand le x devient grand)

je sais si je suis clair




si je comprend, mais dans mon exemple j'ai choisi une autre méthode: limit
toujours "fixe" de type 0,25 et modification dynamique de la requete !