|
| Ordre de lecture d'un fichier HFSQL (Sens du parcour) |
| Iniciado por Sauveur CONSALVI, 31,ene. 2020 16:39 - 18 respuestas |
| |
| | | |
|
| |
Miembro registrado
402 mensajes |
|
| Publicado el 31,enero 2020 - 16:39 |
Bonjour,
J'ai un fichier HFSQL avec une clef composée : Nom et N°
Quand je crée ce fichier, j'écris bien dans l'ordre des n°
Exemple, écriture de TOTO,1 puis TOTO, 2 puis TOTO, 3
Quand je visualise le fichier sous WDMap,, je les trouve affichés dans l'ordre inverse
TOTO 3 puis 2 puis 1
Et quand je fais une boucle de lecture sur ce fichier, les enregistrements sont délivré dans cet ordre, 3,2,1 ...
Pourquoi les enregistrements ne sont-ils pas classés dans l'ordre de la clé composé ?
Cordialement
SC
--
Cordialement
SC |
| |
| |
| | | |
|
| | |
| |
| Publicado el 31,enero 2020 - 17:21 |
Sauveur CONSALVI a écrit :
> Bonjour,
Pourquoi les enregistrements ne sont-ils pas classés dans l'ordre de la clé composé ?
Cordialement
SC
Quelle clé avez-vous indiquée lors du parcours ? |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 01,febrero 2020 - 02:07 |
Bonjour,
Regarde du côté de l'ordre de tri à priori tu as défini un ordre décroissant sur le n°
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
402 mensajes |
|
| Publicado el 01,febrero 2020 - 06:35 |
Bonjour,
Mon problème est bien sur la clef !
J'ai une rubrique NOM Clé avec doublon Ascendant
J'ai une rubrique N° Clé avec doublon Ascendant
J'ai une clé composée formée de NOM et N° Clé unique Ascendant
Je ne trouve pas la bonne syntaxe pour me positionner sur la première rubrique NOM avec la valeur cherchée, puis de parcourir les enregistrements dans l'ordre de la clé composée
Une suggestion ? Merci
Cordialement
SC
--
Cordialement
SC |
| |
| |
| | | |
|
| | |
| |
| Publicado el 01,febrero 2020 - 12:23 |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 01,febrero 2020 - 16:59 |
Bonjour,
Il y a au moins 2 possibilités
1-Via une requète sur le NDX_Nom triée sur NDX_Clé et un parcour sur le résultat de cette requête
2-Via un HlitRechechePremier sur NDX_Nom et le HLitSuivant sur NDX_Clé
Dans les deux cas, la clé composée est inutile. Une CC n'est utile que lorsque l'on fait une recherche sur 2 (ou plus) colonnes
--
Il y a peut être plus simple, mais, ça tourneMensaje modificado, 01,febrero 2020 - 17:02 |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
402 mensajes |
|
| Publicado el 02,febrero 2020 - 07:11 |
Bonjour,
Merci
Je ne maitrise pas bien le HFSQL ...
Sauf erreur de ma part, après le HlitRechechePremier sur NDX_Nom, le HLitSuivant doit utiliser la même clef, sinon il retourne une erreur "Aucun parcours n'a été amorcé pour la rubrique"
Je pense qu'une requête conviendrait mieux, je vais essayer prochainement
--
Cordialement
SC |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 02,febrero 2020 - 10:27 |
En effet, la requête est plus simple à mettre en oeuvre. En réfléchissant, je pense aussi que le la solution HLitRecherche risquedeposer un problème.
Une 3° solution, que personnellement je n'apprécie pas trop, est l'utilisation de HFiltre sur le nom et un parcours sur la clé. Dans ce cas il est important de préciser la clé, sinon le parcours se fera sur la PK.
La requête devrait ressembler à ça:
SELECT
Ville.PK_Ville AS PK_Ville,
Ville.NDX_Ville AS NomVille,
Ville.NDX_CodePostal AS CodePostal
FROM
Ville
WHERE
Ville.NDX_Ville = {pVille}
ORDER BY
CodePostal ASC
--
Il y a peut être plus simple, mais, ça tourneMensaje modificado, 02,febrero 2020 - 10:44 |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
324 mensajes |
|
| Publicado el 03,febrero 2020 - 08:19 |
La syntyaxe suivante, parcours dans l'ordre voulu avec le filtre voulu, pour des petites boucles ou peu d'enregistrement ça peut faire le boulot ^^
POUR TOUT Ville AVEC NDX_Ville = 'Paris' SUR CodePostal
//Code de la boucle
FIN |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 03,febrero 2020 - 09:10 |
Quand je disais qu'il y avait plus simple 
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
| Publicado el 03,febrero 2020 - 13:47 |
Poncherello a écrit :
La syntyaxe suivante, parcours dans l'ordre voulu avec le filtre voulu, pour des petites boucles ou peu d'enregistrement ça peut faire le boulot ^^
POUR TOUT Ville AVEC NDX_Ville = 'Paris' SUR CodePostal
//Code de la boucle
FIN
Bonjour,
Merci, mais j'ai une erreur pour SUR Rubrique .... "Clé de parourt interdite quand les bornes sont précisée"
Cordialement
SC |
| |
| |
| | | |
|
| | |
| |
| Publicado el 03,febrero 2020 - 13:50 |
Même chose
Erreur "Aucun parcours n'a été amorcé pour la rubrique" |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
402 mensajes |
|
| Publicado el 04,febrero 2020 - 10:57 |
Bonjour,
La solution est de passer par une requête, mais je n'aime pas ce genre de programmation, je préfère que tout le code soit immédiatement visible
Comme cette boucle de lecture sert à garnir une table, je trie ensuite la table sur la colonne adéquat
--
Cordialement
SC |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 04,febrero 2020 - 17:37 |
Il suffit de faire le tri dans la requête.
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
166 mensajes |
|
| Publicado el 04,febrero 2020 - 21:22 |
Bonjour;
supprimer la clé composé de HF et Créer une rubrique de type texte et de taille = la somme des tailles des rubriques qui la compose
cette nouvelle rubrique va jouer le rôle de la clé composée
sa valeur doit être affectée avant chaque ajout ou modification dans le fichier
en ce moment vous pouvez l'utiliser dans la recherche et le parcours du fichier
Bon DevMensaje modificado, 04,febrero 2020 - 21:26 |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
402 mensajes |
|
| Publicado el 05,febrero 2020 - 07:31 |
Bonjour,
Effectivement, c'est une solution
C'est d’ailleurs ce que j'ai fait, dans ma table j'ai créé une colonne non visible avec les critères que je désire, et je la trie
Mais dans un fichier, c'est moins évident, car si les rubriques sont nombreuses, on risque de multiplier les clefs
La solution est effectivement la requête, dommage, a mon gout, que l'on ne puisse l'écrire directement dans le code
--
Cordialement
SC |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 05,febrero 2020 - 09:34 |
Le langage "naturel" d'interrogation d'une Base de données relationnelle est le SQL, même si Windev permet de contourner ce "problème" en "camouflant" les requêtes, il faut parfois passer par là.
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
116 mensajes |
|
| Publicado el 05,febrero 2020 - 09:42 |
| Ben si on peut écrire la requête SQL directement dans le code depuis windev 23 je crois |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.362 mensajes |
|
| Publicado el 05,febrero 2020 - 11:12 |
Plus ou moins, mais oui.
On pouvait déjà avant et on l'exécutait via HExécuteRequêteSQL. Le principe est le même et on peut utiliser le passage de paramètre Windev au lieu de passer par ChaineConstruit
--
Il y a peut être plus simple, mais, ça tourne |
| |
| |
| | | |
|
| | | | |
| | |
|