wahidov2000
Messages postés31Date d'inscriptionmercredi 9 novembre 2005StatutMembreDernière intervention15 septembre 2013
-
15 mars 2009 à 10:40
wahidov2000
Messages postés31Date d'inscriptionmercredi 9 novembre 2005StatutMembreDernière intervention15 septembre 2013
-
16 mars 2009 à 16:48
bonjour tm,
J’utilise delphi 7 et sql serveur 2005 pour développé une application, j’ai l’habitude de travaillé avec la fonction LIKE pour le filtre des tables sans aucun problème jusqu'au moment ou j’ai voulu faire un filtre sur la clé primaire d’une table (la clé est de type float) et j'ai pas eu de bon résultat.
Quand la clé ne dépasse pas les 6 positions (100.000) j’ai le résultat attendu mais dés qu’elle dépasse ça le résultat est faux
Ma requête est la suivante :
trep.CommandText:='select * from table1 where CODE_ART like'+quotedStr('%'+trim(pv.text)+'%');
wahidov2000
Messages postés31Date d'inscriptionmercredi 9 novembre 2005StatutMembreDernière intervention15 septembre 2013 16 mars 2009 à 16:48
merci pour vos reponses (f0xi et cantador)
je pense que j'ai trouvé une simple solution, je copie la valeur du champs CODE_ART de type float dans un autre champs de type string et j'utilises like avec ce deuxieme champs
wahidov2000
Messages postés31Date d'inscriptionmercredi 9 novembre 2005StatutMembreDernière intervention15 septembre 2013 15 mars 2009 à 13:00
merci f0xi pour votre reponse mais dans mmon cas je dois filtré les chiffres (c un code composé sur 12 positions par exple les 3 premiers c'est la nature le 4 et 5ieme correspondent a l'acheteur .....)
donc pour avoir les article (CODE_ART) du nature 201 je doit affiché tout les code qui commence par 201
wahidov
f0xi
Messages postés4205Date d'inscriptionsamedi 16 octobre 2004StatutModérateurDernière intervention12 mars 202235 15 mars 2009 à 15:45
alors n'utilise pas le type FLOAT, mais plutot le type INTEGER (entier long) ou VARCHAR.
le type float n'est vraiment pas adapté a ce genre d'utilisation contrairement aux deux autres que je viens de de citer.
le type float en binaire ne peut etre interpreté de façon claire et peu poser des problemes de convertion ou de precision comme tu l'a constater.
les types entiers ou varchar se pretent mieux a ce genre de jeux, de façon plus fiable et efficace.
le type varchar par exemple peu aussi bien etre interpreté en chiffre (quand il est composé uniquement de cela) ou de texte (quand il contient des lettres).
exemple de code avec varchar :
A201HC33
A201FX76
B202HC33
... WHERE CODE_ART LIKE 'A201%' ... fonctionnera parfaitement.
et nous donnera que les codes A201 ...
n'oublie pas qu'en code il faut "penser" correctement les données, aussi bien dans leur presentation brute que leur utilisation pour le developpeur et l'utilisateur.
un exemple flagrant par exemple avec les codes barres dont le numero est trés important ...
Vous n’avez pas trouvé la réponse que vous recherchez ?
cs_cantador
Messages postés4720Date d'inscriptiondimanche 26 février 2006StatutModérateurDernière intervention31 juillet 202113 15 mars 2009 à 19:48
Bonsoir,
(c un code composé sur 12 positions par exple les 3 premiers c'est la nature le 4 et 5ieme correspondent a l'acheteur .....)
Si ta clé primaire n'est pas atomique, c'est qu'il doit y avoir une erreur de modélisation quelque part ce qui arrive assez fréquemment (des tables cachées qui n'ont pas été créée..etc)
pas tout à fait la réponse à ta question mais c'est bon de la savoir..
f0xi
Messages postés4205Date d'inscriptionsamedi 16 octobre 2004StatutModérateurDernière intervention12 mars 202235 16 mars 2009 à 16:20
pour ce qui est du codage, je dirais même que les codes serait mieux dans des champs séparé :
nature (byte / word / set)
acheteur (dword)
cela offrira un plus large choix ... 2 chiffres pour l'acheteur cela me semble assé limité (limite 100) alors que nature est plus confortable (1000 natures)
n'oublie pas de bien penser tes données selon l'utilisation et la souplesse que tu veux y laisser.
j'avais fait une erreur du genre sur une base de donnée pour l'ID des messages (word) donc erreur quand on depasse 65536 messages ...
depuis dés que j'ai un ID j'utilise directement un entier 64bit (long long int / large int) comme ça plus de limitation.
ce n'est qu'un exemple parmis tant d'autre, comme par exemple le stockage des mdp sous forme de hash (md5 / sha) on m'avait demandé de modifier la clef pour passer d'un 256bits a une clef 512bits cela n'etant pas prevus dés le depart j'ai dus remodifier le champs ... depuis ... a l'identique des ID, je prevois un champs qui peu contenir des clefs 512bits des le depart, même si l'enregistrement se fait uniquement avec des clefs 128 ou 256 bits...
voila.