@[b]Xenon_54[/b] : Effectivement, c'est la base de mon soucis. Je ne comprend pas pourquoi les guillemets déclenchent une erreur quand j'ai un entier > 6 400 000 000 000 000 000 (19 digits)

@[b]Ripat[/b] : les nombres commencent à déconner bien avant cette limite puisqu'avec 19 digits commençant par "64...", l'insert se passe bien, j'ai bien la bonne valeur en base de données, mais tout select avec des ' autour de la valeur ne retourne rien :-k

@[b]Ajoloca[/b] : Effectivement, je garde cette solution sous le coude. Mais j'ai déjà diminué la taille maximale et j'ai finit le développement de ce projet. J'en toucherais mot à mon chef pour la prochaine conception sur ce projet ;)

En tout cas, merci à vous pour vos réponses et vos conseils :pouce:

Bonjour,

Pourquoi ne pas stocker la valeur dans une colonne de type DECIMAL (20, 0) UNSIGNED ?

[url=http://dev.mysql.com/doc/refman/5.0/fr/numeric-type-overview.html]Une info[/url] assez parlante.

BIGINT et un type de colonne sur 8 octets. En conséquence, la valeur max est de (2^64)-1 soit 18446744073709551615

Avec un entier non signé de 20 chiffres commençant par 64, tu dépasses la valeur maximum pour ce type de colonne. Lors dun INSERT d'une valeur trop élévée, MySQL ne se plaindra pas, il te mettra la valeur max soit 18446744073709551615.

[code]INSERT INTO b (col1) VALUES (18446744073709551616)
INSERT INTO b (col1) VALUES (99999999999999999999)
[/code]

Produiront tous deux un insert de la valeur entière 18446744073709551615

Si tu dois stocker des nombres plus élévés, il faudra te tourner vers les types chaîne.

As-tu essayé en retirant les guillemets simples? Peut-être qu'il convertir ta chaine en INTEGER et non en bigint().

Bonsoir, je ne suis pas spécialiste mais je pense avoir eu le même problème. En y regardant de plus près, j'ai eu l'impression que, si je reprends ton exemple :

[code]DELETE FROM entree WHERE id_entree = '....'[/code]

le moteur exécutait de la sorte :

[code]DELETE FROM entree WHERE id_entree = "'"...."'"[/code]

Une sorte de protection, ceci me changeait tout... Néanmoins, be careful, je débute...

Il me semble que du point de vue de la norme SQL ANSI, il est possible d'entourer un entier par des '.
Dans un point de vue de compatibilité ascendante (il est possible que ce chiffre soit remplacé par un UUID) j'ai préféré écrire les requêtes comme ça pour pas avoir à me le retaper ensuite.

Sinon, pour le "default '0'", comme je l'ai indiqué, je donne TOUJOURS une valeur par défaut. L'expérience m'a appris que la base d'un bug, c'est la suffisance du développeur. La confiance absolue en ce qu'il a fait. Et cette expérience ne m'a jamais porté préjudice.
Dans ce cas, je sais que si, pour une raison x ou y (un autre développeur qui change la primary key ou le NOT NULL par exemple), je maitrise encore ce qui se passe dans cette colonne.

Et puis, un point pour moi, le "default '0'", c'est de cette manière que le génère PMA ;)

je suppose que à partir du moment ou tu entoure ton nombre par des quotes, tu déclenche une conversion implicite en un type inférieur à bigint, d'où arrondi au plafond... (au lieu d'une erreur qui serait plus logique)

à propos de logique, y'a une raison pour laquelle tu entoure les chiffres de quote? déjà... default '0' au lieu de default 0 (qui sert à rien non plus mais bon) :lol:

C'est un [i]bug[/i] intéressant, si tu ne trouves pas la réponse ça vaut peut-être le coup de le soumettre. En attendant, je le note pour plus tard quand on me demandera pourquoi il faut pas mettre de guillemets autour des nombres :lol:

Bonjour à tous,

Au cours de mon travail, je suis tombé sur un bug que je juge bizarre.

J'ai une table 'entree' qui contient, comme clé primaire, un champ 'id_entree' définie comme telle :
[code]`id_entree` bigint(20) unsigned NOT NULL default '0'[/code]
(Je met toujours un default ... même si c'est inutile ;) )

Dans cette colonne, à chaque insertion, je génère un identifiant aléatoire qui peut varier entre 17 et 20 digits.

Le traitement que j'applique dessus commence par un [code]SELECT * FROM entree LIMIT 0, 50000[/code] qui fonctionne parfaitement, qui me remonte toutes les valeurs, y compris l'id_entree.
Or, après ce traitement, j'ai un DELETE unitaire de cette forme
[code]DELETE FROM entree WHERE id_entree = '....'[/code]
Et, ici, je me suis rendu compte que si j'encadre mon id par des ', tous id > 19 digits commençant par '64...' n'est pas supprimé. Je n'arrive pas à le sélectionner non plus :-k

Dès que j'enlève les ', plus de soucis, SELECT et DELETE fonctionnent parfaitement :shock:

Je me demandais donc si quelqu'un pouvait m'expliquer pourquoi :?:

PS : pour le bug, pas de soucis, j'ai réduit la génération aléatoire entre 15 et 18 digit, ce qui est encore quelques centaines de fois supérieure à ce qui peut se trouver simultanément dans la table ...