UPDATE matable SET champ_numerique = '' WHERE macondition;
Mysql répond Incorrect integer value.
Sur 1and1.fr ça passe, j'ai bati tous mes scripts de cette façon et
voilà que mes scripts ne passent plus sur une autre config.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoun
Julien Arlandis wrote:
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Mysql répond Incorrect integer value. Sur 1and1.fr ça passe, j'ai bati tous mes scripts de cette façon et voilà que mes scripts ne passent plus sur une autre config.
Quelqu'un a une solution?
tu devrais afficher ta valeur, histoire de vérifier qu'il n'y a pas un caractère bizarre qui se serait glissé dans ta valeur.
Julien Arlandis wrote:
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Mysql répond Incorrect integer value.
Sur 1and1.fr ça passe, j'ai bati tous mes scripts de cette façon et
voilà que mes scripts ne passent plus sur une autre config.
Quelqu'un a une solution?
tu devrais afficher ta valeur, histoire de vérifier qu'il n'y a pas un
caractère bizarre qui se serait glissé dans ta valeur.
UPDATE matable SET champ_numerique = '' WHERE macondition;
Mysql répond Incorrect integer value. Sur 1and1.fr ça passe, j'ai bati tous mes scripts de cette façon et voilà que mes scripts ne passent plus sur une autre config.
Quelqu'un a une solution?
tu devrais afficher ta valeur, histoire de vérifier qu'il n'y a pas un caractère bizarre qui se serait glissé dans ta valeur.
Julien Arlandis
Antoun a écrit :
Julien Arlandis wrote:
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Mysql répond Incorrect integer value. Sur 1and1.fr ça passe, j'ai bati tous mes scripts de cette façon et voilà que mes scripts ne passent plus sur une autre config.
Quelqu'un a une solution?
tu devrais afficher ta valeur, histoire de vérifier qu'il n'y a pas un caractère bizarre qui se serait glissé dans ta valeur.
C'est ce que j'ai fait, apparemment d'après ce que j'ai lu le problème viendrait de Mysql 5 qui refuserait d'updater un entier mal formaté. Galère pour updater les checkbox lorsqu'ils ne sont pas cochés, surtout que j'ai pas mal de scripts automatiques qui gèrent les mises à jour de formulaires, me voilà bien emmerdé...
Antoun a écrit :
Julien Arlandis wrote:
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Mysql répond Incorrect integer value.
Sur 1and1.fr ça passe, j'ai bati tous mes scripts de cette façon et
voilà que mes scripts ne passent plus sur une autre config.
Quelqu'un a une solution?
tu devrais afficher ta valeur, histoire de vérifier qu'il n'y a pas un
caractère bizarre qui se serait glissé dans ta valeur.
C'est ce que j'ai fait, apparemment d'après ce que j'ai lu le problème
viendrait de Mysql 5 qui refuserait d'updater un entier mal formaté.
Galère pour updater les checkbox lorsqu'ils ne sont pas cochés, surtout
que j'ai pas mal de scripts automatiques qui gèrent les mises à jour de
formulaires, me voilà bien emmerdé...
UPDATE matable SET champ_numerique = '' WHERE macondition;
Mysql répond Incorrect integer value. Sur 1and1.fr ça passe, j'ai bati tous mes scripts de cette façon et voilà que mes scripts ne passent plus sur une autre config.
Quelqu'un a une solution?
tu devrais afficher ta valeur, histoire de vérifier qu'il n'y a pas un caractère bizarre qui se serait glissé dans ta valeur.
C'est ce que j'ai fait, apparemment d'après ce que j'ai lu le problème viendrait de Mysql 5 qui refuserait d'updater un entier mal formaté. Galère pour updater les checkbox lorsqu'ils ne sont pas cochés, surtout que j'ai pas mal de scripts automatiques qui gèrent les mises à jour de formulaires, me voilà bien emmerdé...
Patrick Mevzek
Le Wed, 26 Jul 2006 20:27:03 +0200, Julien Arlandis a écrit :
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Depuis quand une chaîne vide est-elle une valeur numérique ?
Si d'anciennes versions de SGBDR, comme MySQL, étaient laxistes, ce n'est pas le cas de SGBDR dignes de ce nom.
Vous ne pouvez mettre donc dans votre champ numérique... qu'une valeur numérique, ou NULL éventuellement.
Quelqu'un a une solution?
Respecter le typage SQL. Donc, au final, corriger votre UPDATE.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Wed, 26 Jul 2006 20:27:03 +0200, Julien Arlandis a écrit :
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Depuis quand une chaîne vide est-elle une valeur numérique ?
Si d'anciennes versions de SGBDR, comme MySQL, étaient laxistes, ce n'est
pas le cas de SGBDR dignes de ce nom.
Vous ne pouvez mettre donc dans votre champ numérique... qu'une valeur
numérique, ou NULL éventuellement.
Quelqu'un a une solution?
Respecter le typage SQL.
Donc, au final, corriger votre UPDATE.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Wed, 26 Jul 2006 20:27:03 +0200, Julien Arlandis a écrit :
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Depuis quand une chaîne vide est-elle une valeur numérique ?
Si d'anciennes versions de SGBDR, comme MySQL, étaient laxistes, ce n'est pas le cas de SGBDR dignes de ce nom.
Vous ne pouvez mettre donc dans votre champ numérique... qu'une valeur numérique, ou NULL éventuellement.
Quelqu'un a une solution?
Respecter le typage SQL. Donc, au final, corriger votre UPDATE.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Julien Arlandis
Patrick Mevzek a écrit :
Le Wed, 26 Jul 2006 20:27:03 +0200, Julien Arlandis a écrit :
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Depuis quand une chaîne vide est-elle une valeur numérique ?
Si d'anciennes versions de SGBDR, comme MySQL, étaient laxistes, ce n'est pas le cas de SGBDR dignes de ce nom.
Vous ne pouvez mettre donc dans votre champ numérique... qu'une valeur numérique, ou NULL éventuellement.
C'était très pratique, quel avantage ça apporte de respecter le typage SQL autre que de respecter le typage SQL? Avant je pouvais traiter tous les champs de formulaires de la même façon maintenant je suis obligé de traiter au cas par cas les champs manipulés par les checkbox car je suis obligé de rajouter manuellement la valeur 0.
Quelqu'un a une solution?
Respecter le typage SQL. Donc, au final, corriger votre UPDATE.
Patrick Mevzek a écrit :
Le Wed, 26 Jul 2006 20:27:03 +0200, Julien Arlandis a écrit :
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Depuis quand une chaîne vide est-elle une valeur numérique ?
Si d'anciennes versions de SGBDR, comme MySQL, étaient laxistes, ce n'est
pas le cas de SGBDR dignes de ce nom.
Vous ne pouvez mettre donc dans votre champ numérique... qu'une valeur
numérique, ou NULL éventuellement.
C'était très pratique, quel avantage ça apporte de respecter le typage
SQL autre que de respecter le typage SQL?
Avant je pouvais traiter tous les champs de formulaires de la même façon
maintenant je suis obligé de traiter au cas par cas les champs manipulés
par les checkbox car je suis obligé de rajouter manuellement la valeur 0.
Quelqu'un a une solution?
Respecter le typage SQL.
Donc, au final, corriger votre UPDATE.
Le Wed, 26 Jul 2006 20:27:03 +0200, Julien Arlandis a écrit :
J'appelle une requête de ce type (par php) :
UPDATE matable SET champ_numerique = '' WHERE macondition;
Depuis quand une chaîne vide est-elle une valeur numérique ?
Si d'anciennes versions de SGBDR, comme MySQL, étaient laxistes, ce n'est pas le cas de SGBDR dignes de ce nom.
Vous ne pouvez mettre donc dans votre champ numérique... qu'une valeur numérique, ou NULL éventuellement.
C'était très pratique, quel avantage ça apporte de respecter le typage SQL autre que de respecter le typage SQL? Avant je pouvais traiter tous les champs de formulaires de la même façon maintenant je suis obligé de traiter au cas par cas les champs manipulés par les checkbox car je suis obligé de rajouter manuellement la valeur 0.
Quelqu'un a une solution?
Respecter le typage SQL. Donc, au final, corriger votre UPDATE.
Patrick Mevzek
Le Wed, 26 Jul 2006 21:46:04 +0200, Julien Arlandis a écrit :
C'était très pratique, quel avantage ça apporte de respecter le typage SQL autre que de respecter le typage SQL?
Vous connaissez l'acronyme GIGO ? Ou, autre exemple typique MySQL, la «date» 0000-00-00 (qui n'en est pas une, regardez votre calendrier...) ?
J'imagine que, dans la série, les contraintes, les transactions et tout le reste, cela ne sert à rien, c'est ca ?
Si vous voulez absolument contourner le typage, vous créez tous vos champs en text et mettez n'importe quoi dedans. Vous serez heureux alors, vous allez voir...
Pourquoi vous êtes vous compliqué la vie pour explicitement demander que votre attribut soit numérique si vous ne voulez pas que le SGBDR le vérifie et le respecte ?
Avant je pouvais traiter tous les champs de formulaires de la même façon
Avant, vous faisiez mal. Il ne vous reste donc qu'à changer.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Wed, 26 Jul 2006 21:46:04 +0200, Julien Arlandis a écrit :
C'était très pratique, quel avantage ça apporte de respecter le typage
SQL autre que de respecter le typage SQL?
Vous connaissez l'acronyme GIGO ?
Ou, autre exemple typique MySQL, la «date» 0000-00-00 (qui n'en est pas
une, regardez votre calendrier...) ?
J'imagine que, dans la série, les contraintes, les transactions et tout
le reste, cela ne sert à rien, c'est ca ?
Si vous voulez absolument contourner le typage, vous créez tous vos
champs en text et mettez n'importe quoi dedans. Vous serez heureux alors,
vous allez voir...
Pourquoi vous êtes vous compliqué la vie pour
explicitement demander que votre attribut soit numérique si vous ne
voulez pas que le SGBDR le vérifie et le respecte ?
Avant je pouvais traiter tous les champs de formulaires de la même façon
Avant, vous faisiez mal.
Il ne vous reste donc qu'à changer.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Wed, 26 Jul 2006 21:46:04 +0200, Julien Arlandis a écrit :
C'était très pratique, quel avantage ça apporte de respecter le typage SQL autre que de respecter le typage SQL?
Vous connaissez l'acronyme GIGO ? Ou, autre exemple typique MySQL, la «date» 0000-00-00 (qui n'en est pas une, regardez votre calendrier...) ?
J'imagine que, dans la série, les contraintes, les transactions et tout le reste, cela ne sert à rien, c'est ca ?
Si vous voulez absolument contourner le typage, vous créez tous vos champs en text et mettez n'importe quoi dedans. Vous serez heureux alors, vous allez voir...
Pourquoi vous êtes vous compliqué la vie pour explicitement demander que votre attribut soit numérique si vous ne voulez pas que le SGBDR le vérifie et le respecte ?
Avant je pouvais traiter tous les champs de formulaires de la même façon
Avant, vous faisiez mal. Il ne vous reste donc qu'à changer.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Julien Arlandis
Patrick Mevzek a écrit :
Le Wed, 26 Jul 2006 21:46:04 +0200, Julien Arlandis a écrit :
C'était très pratique, quel avantage ça apporte de respecter le typage SQL autre que de respecter le typage SQL?
Vous connaissez l'acronyme GIGO ? Ou, autre exemple typique MySQL, la «date» 0000-00-00 (qui n'en est pas une, regardez votre calendrier...) ?
J'imagine que, dans la série, les contraintes, les transactions et tout le reste, cela ne sert à rien, c'est ca ?
Si vous voulez absolument contourner le typage, vous créez tous vos champs en text et mettez n'importe quoi dedans. Vous serez heureux alors, vous allez voir...
Pourquoi vous êtes vous compliqué la vie pour explicitement demander que votre attribut soit numérique si vous ne voulez pas que le SGBDR le vérifie et le respecte ?
Avant je pouvais traiter tous les champs de formulaires de la même façon
Avant, vous faisiez mal.
Erreur, avant je travaillais beaucoup plus vite et ça marchait. C'est la seule et unique chose qui compte, le reste c'est du blabla philosophique, maintenant je vais être obligé à me faire chier à vérifier le type des données avant de les insérer alors que mysql le faisait pour moi.
Il ne vous reste donc qu'à changer.
Patrick Mevzek a écrit :
Le Wed, 26 Jul 2006 21:46:04 +0200, Julien Arlandis a écrit :
C'était très pratique, quel avantage ça apporte de respecter le typage
SQL autre que de respecter le typage SQL?
Vous connaissez l'acronyme GIGO ?
Ou, autre exemple typique MySQL, la «date» 0000-00-00 (qui n'en est pas
une, regardez votre calendrier...) ?
J'imagine que, dans la série, les contraintes, les transactions et tout
le reste, cela ne sert à rien, c'est ca ?
Si vous voulez absolument contourner le typage, vous créez tous vos
champs en text et mettez n'importe quoi dedans. Vous serez heureux alors,
vous allez voir...
Pourquoi vous êtes vous compliqué la vie pour
explicitement demander que votre attribut soit numérique si vous ne
voulez pas que le SGBDR le vérifie et le respecte ?
Avant je pouvais traiter tous les champs de formulaires de la même façon
Avant, vous faisiez mal.
Erreur, avant je travaillais beaucoup plus vite et ça marchait.
C'est la seule et unique chose qui compte, le reste c'est du blabla
philosophique, maintenant je vais être obligé à me faire chier à
vérifier le type des données avant de les insérer alors que mysql le
faisait pour moi.
Le Wed, 26 Jul 2006 21:46:04 +0200, Julien Arlandis a écrit :
C'était très pratique, quel avantage ça apporte de respecter le typage SQL autre que de respecter le typage SQL?
Vous connaissez l'acronyme GIGO ? Ou, autre exemple typique MySQL, la «date» 0000-00-00 (qui n'en est pas une, regardez votre calendrier...) ?
J'imagine que, dans la série, les contraintes, les transactions et tout le reste, cela ne sert à rien, c'est ca ?
Si vous voulez absolument contourner le typage, vous créez tous vos champs en text et mettez n'importe quoi dedans. Vous serez heureux alors, vous allez voir...
Pourquoi vous êtes vous compliqué la vie pour explicitement demander que votre attribut soit numérique si vous ne voulez pas que le SGBDR le vérifie et le respecte ?
Avant je pouvais traiter tous les champs de formulaires de la même façon
Avant, vous faisiez mal.
Erreur, avant je travaillais beaucoup plus vite et ça marchait. C'est la seule et unique chose qui compte, le reste c'est du blabla philosophique, maintenant je vais être obligé à me faire chier à vérifier le type des données avant de les insérer alors que mysql le faisait pour moi.
Il ne vous reste donc qu'à changer.
Patrick Mevzek
Le Thu, 27 Jul 2006 00:47:05 +0200, Julien Arlandis a écrit :
Avant, vous faisiez mal.
Erreur, avant je travaillais beaucoup plus vite et ça marchait.
Vous n'utilisez pas correctement l'outil à votre disposition.
On peut certes taper sur un clou avec un tournevis plutôt qu'un marteau, mais il y a des risques.
Si vous êtes persuadé de tout savoir et de mieux faire que tout le monde, je pense qu'il est inutile de venir poser des questions ici.
C'est la seule et unique chose qui compte, le reste c'est du blabla philosophique, maintenant je vais être obligé à me faire chier à vérifier le type des données avant de les insérer alors que mysql le faisait pour moi.
Vous n'avez rien compris, ni au problème, ni à la solution.
PHP & Mysql ca fait vraiment des ravages, comme le Pascal. Ca déforme plus que ca ne forme, on en voit bien les résultats.
Fin de la discussion pour moi.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Thu, 27 Jul 2006 00:47:05 +0200, Julien Arlandis a écrit :
Avant, vous faisiez mal.
Erreur, avant je travaillais beaucoup plus vite et ça marchait.
Vous n'utilisez pas correctement l'outil à votre disposition.
On peut certes taper sur un clou avec un tournevis plutôt qu'un
marteau, mais il y a des risques.
Si vous êtes persuadé de tout savoir et de mieux faire que tout le
monde, je pense qu'il est inutile de venir poser des questions ici.
C'est la seule et unique chose qui compte, le reste c'est du blabla
philosophique, maintenant je vais être obligé à me faire chier à
vérifier le type des données avant de les insérer alors que mysql le
faisait pour moi.
Vous n'avez rien compris, ni au problème, ni à la solution.
PHP & Mysql ca fait vraiment des ravages, comme le Pascal.
Ca déforme plus que ca ne forme, on en voit bien les résultats.
Fin de la discussion pour moi.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Thu, 27 Jul 2006 00:47:05 +0200, Julien Arlandis a écrit :
Avant, vous faisiez mal.
Erreur, avant je travaillais beaucoup plus vite et ça marchait.
Vous n'utilisez pas correctement l'outil à votre disposition.
On peut certes taper sur un clou avec un tournevis plutôt qu'un marteau, mais il y a des risques.
Si vous êtes persuadé de tout savoir et de mieux faire que tout le monde, je pense qu'il est inutile de venir poser des questions ici.
C'est la seule et unique chose qui compte, le reste c'est du blabla philosophique, maintenant je vais être obligé à me faire chier à vérifier le type des données avant de les insérer alors que mysql le faisait pour moi.
Vous n'avez rien compris, ni au problème, ni à la solution.
PHP & Mysql ca fait vraiment des ravages, comme le Pascal. Ca déforme plus que ca ne forme, on en voit bien les résultats.
Fin de la discussion pour moi.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
