Index fichier de type libellé (codé sur 4 octet)

Bonjour,

J'ai une table dont l'identifiant automatique est de type libellé (Texte multi-ligne) codé sur 4 octet en clé unique.

Tout fonctionne normalement à l'exception du passage paramètre vers la requête utilisé pour un état.

Code:

---

1 2 3 4 5

GC_REQ_Details_Sigles.Param1 = GC_TABLE_Sigle.GC_COL_IDSIGLE   HExécuteRequête(GC_REQ_Details_Sigles)

---

Dans le principe, lorsque je sélectionne la ligne de la table Sigle avec comme index IDSIGLE = (11 par exemple) :

Code:

---

info(GC_TABLE_Sigle.GC_COL_IDSIGLE)

---

J'obtiens "11" en affichage


Maintenant, lorsque je passe ce même code en paramètre à ma requête :

Code:

---

GC_REQ_Details_Sigles.Param1 = GC_TABLE_Sigle.GC_COL_IDSIGLE

---

J'obtiens "0x0000000B" en affichage soit un codage hexa sur 4 octets...

Bien évidement, la requête n'affiche "aucun résultat" puisque le texte passé en paramètre "0x0000000B" n'est pas identique celui du fichier "11"


1°) Question

- Y a t'il une fonction de conversion existante et simple à mettre en oeuvre... ou une autre solution ?

J'utilise rarement ce type de rubrique (libellé) dans mes fichiers, mais là c'est une table exploitée par d'autres et donc je ne peux pas dans l'immédiat modifié cette rubrique pour la substituer par un entier.

2°) Question

- Ma requête utilise ce param1 pour filtrer et obtenir 1 ligne enregistrée.

Cependant, je voudrais pouvoir aussi afficher l'ensemble des lignes en inhibant ce param1 dans la requête... Y a t'il moyen de décocher le param1 par programmation

Merci à vous

Normalement un id auto, c'est un entier.

Partant de là, tu devrais y voir plus clair, non ?

Question 1 :
Je ne comprends pas bien cette histoire de paramètre en hexa.. il existe hexaversentier je crois... je sais pas si ça t'aide.

Question 2 :
Pour "ignorer" une clause il faut balancer Null dans le paramètre (ou ne pas lui affecter de valeur).

Citation:

---

Envoyé par frenchsting

Normalement un id auto, c'est un entier.

Partant de là, tu devrais y voir plus clair, non ?

---

Effectivement c'est aussi mon point de vue mais ce n'est pas moi qui ait créé cette table et donc pour ne pas modifier le fichier initial qui sert ailleurs, je poursuis avec...

A mon sens, le fait d'avoir une valeur codée sur 4 octets (du type : 0x0000000C") lui donnait beaucoup plus de valeurs possibles puisque base 16 (hexa) et non 10 (décimal).

Bonjour

Citation:

---

Envoyé par GCASPIC10

A mon sens, le fait d'avoir une valeur codée sur 4 octets (du type : 0x0000000C") lui donnait beaucoup plus de valeurs possibles puisque base 16 (hexa) et non 10 (décimal).

---

Qu'est-ce qu'il ne faut pas lire...
4 octets permettent 2^32 possibilités. Ni plus, ni moins. Ensuite qu'il soit affiché en hexa, en décimal ou en octal ou sous forme de chaine de caractères ne change strictement rien ici, ce n'est que de l'interprétation pour le rendre lisible.

Tatayo.

C'est effectivement plutôt comique ! :mouarf:

Citation:

---

Envoyé par michel.souris

C'est effectivement plutôt comique ! :mouarf:

---

Je vais peut être m'enfoncer un peu plus ... çà fait trop longtemps que je n'y ais pas mis les pieds, mais il me semble que :

en binaire (0-1) : 2 possibilités
en décimal (0-9) : 10 possibilités
en hexa (0-F) : 16 possibilités


en fait j'ai dû cocher quelque chose ... quelque part dans Windev qui m'affiche dans le debug, lors du survole de toutes mes variables un contenu en hexa (du style "30 30 30 32" pour en réalité une valeur = "2").

Je ne sais pas si je m'explique bien en tout cas çà vous faire rire et c'est plutôt bon pour la santé. Ou décocher cette option SVP !

Oui sur un digit il y a plus de possibilité en hexa qu'en décimal et en décimal qu'en binaire...

Mais quand tu dis j'ai un entier sur 4 octets (soit 32 bits) ça donne au maximum (et non signé) :
11111111111111111111111111111111 en binaire
FFFFFFFF en héxa
et 4294967295 en décimal

(j'espère à mon tour ne pas dire de bêtise)

Pour le débogueur il y a un bouton avec écrit "hexa" dans le kougloff (sic), juste au dessus de l'évaluation des expressions, tu vois ?

Je n'étais pas le seul à chercher...


http://forum.pcsoft.fr/fr-FR/pcsoft....ables/read.awp

Enfin, j'ai recherché dans bon nombre de barres pour effectivement le trouver dans la fenêtre "Editeur de code" onglet "Debugger" icone "Hexa"

Merci pour l'info

Sinon, je me suis sans doute mal exprimé car "GC_TABLE_Sigle.GC_COL_IDSIGLE" est une chaine multi-texte (de type libellé) codé sur 4 octets qui me donne ("0010" et donc "0x0000000A")

Moi c'est dès le premier message que j'ai bondi au ciel :

J'ai une table dont l'identifiant automatique est de type libellé (Texte multi-ligne) codé sur 4 octet en clé unique.

Dans l'éditeur d'analyse de Windev, on voit effectivement que les champs de type texte multi-ligne (ou différents autres champs Mémo ... ..) occupent 4 octets.

Oui et non !

Quand il y a un champ mémo ou assimilé dans une analyse, HFSQL va écrire ce champ dans un fichier .MMO , et il va écrire aussi un code numérique sur 4 octets.
Et il va dupliquer ce code sur 4 octets dans le fichier FIC.
Donc effectivement , dans le fichier FIC, ce champ ne va prendre que 4 octets.

Je ne sais pas si on doit bondir de plaisir car comme on s'en doute le but de toute application est de réduire la masse d'octets utiliser pour gérer une information. L'avantage des BD est de réduire les doublons et surtout les redondances...
Bref, le fait de faire appel à un autre fichier pour stocker des infos (mémo entre autre) est donc un doublon en terme de volume d'info ! Cela peut se concevoir pour des saisies de texte mais pas trop pour des index ... Pas GLOUP

Ce que tbc92 vous explique c'est que votre identifiant n'est absolument pas stocké sur 4 octets. Et il a raison.