resultat de la fonction like (delphi sql serveur 2005)

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)+'%');

trep (ADO data set )

CODE_ART (la clé de la table1)

pv (Tedit)

Merci d'avance pour vos réponses

 

pour les chiffres ce serait mieux de mettre un filtre d'interval :

WHERE CODE_ART >= 100 AND CODE_ART < 101

aprés je ne sais pas si cela correspond a ce que tu veux faire.

LIKE c'est bien pour le texte ...

---

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

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 ...

---

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..

cantador

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.

---