Je migre actuellement de Sql Server vers MySQL une application dans
laquelle de cochonnes requ=EAtes d'insertion ont =E9t=E9 =E9crites en
ins=E9rant
des chaines vides (=3D'') =E0 la place d'un NULL pour les champs date non
renseign=E9s.
Si Sql Server supportait sans probl=E8me cet abus (il transforme
automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec
une date dont la valeur est vide. J'ai tent=E9 d'utiliser les options
possibles de sql_mode, mais sans succ=E8s.
Vu le volume de l'application, il para=EEt injouable de repasser chaque
requ=EAte pour la modifier ad=E9quatement, et remplacer les '' par des
NULL.
Quelqu'un conna=EEt-il le param=E8tre miracle qui va nous d=E9bloquer ?
Merci d'avance.
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
Daniel
Bonjour, "MiF" writes:
Bonjour,
Je migre actuellement de Sql Server vers MySQL une application dans laquelle de cochonnes requêtes d'insertion ont été écrites en ins érant des chaines vides (='') à la place d'un NULL pour les champs date non renseignés.
Si Sql Server supportait sans problème cet abus (il transforme automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec une date dont la valeur est vide. J'ai tenté d'utiliser les options possibles de sql_mode, mais sans succès.
Vu le volume de l'application, il paraît injouable de repasser chaque requête pour la modifier adéquatement, et remplacer les '' par des NULL.
Il n'y a pas de difficulté si : - ta rubrique est paramétré pour recevoir un Null - si tu envoies un Null pour la date.
Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te renvoie une alerte mais c'est bon.
en faisant :
set GLOBAL sql_mode='ANSI';
celà doit passer (à condition que tu ais les droits ;-))
Sinon au pire si ne marche toujours pas faire une colonne du type char et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu fais une fonction en sql qui copie ta colonne temporarire vers ta colonne date en convertissant explicitement ta chaine en date
Quelqu'un connaît-il le paramètre miracle qui va nous débloquer ? Merci d'avance.
Michel Fages
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Bonjour,
"MiF" <michel.fages@gmail.com> writes:
Bonjour,
Je migre actuellement de Sql Server vers MySQL une application dans
laquelle de cochonnes requêtes d'insertion ont été écrites en ins érant
des chaines vides (='') à la place d'un NULL pour les champs date non
renseignés.
Si Sql Server supportait sans problème cet abus (il transforme
automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec
une date dont la valeur est vide. J'ai tenté d'utiliser les options
possibles de sql_mode, mais sans succès.
Vu le volume de l'application, il paraît injouable de repasser chaque
requête pour la modifier adéquatement, et remplacer les '' par des
NULL.
Il n'y a pas de difficulté si :
- ta rubrique est paramétré pour recevoir un Null
- si tu envoies un Null pour la date.
Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te
renvoie une alerte mais c'est bon.
en faisant :
set GLOBAL sql_mode='ANSI';
celà doit passer (à condition que tu ais les droits ;-))
Sinon au pire si ne marche toujours pas faire une colonne du type char
et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu
fais une fonction en sql qui copie ta colonne temporarire vers ta
colonne date en convertissant explicitement ta chaine en date
Quelqu'un connaît-il le paramètre miracle qui va nous débloquer ?
Merci d'avance.
Michel Fages
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Je migre actuellement de Sql Server vers MySQL une application dans laquelle de cochonnes requêtes d'insertion ont été écrites en ins érant des chaines vides (='') à la place d'un NULL pour les champs date non renseignés.
Si Sql Server supportait sans problème cet abus (il transforme automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec une date dont la valeur est vide. J'ai tenté d'utiliser les options possibles de sql_mode, mais sans succès.
Vu le volume de l'application, il paraît injouable de repasser chaque requête pour la modifier adéquatement, et remplacer les '' par des NULL.
Il n'y a pas de difficulté si : - ta rubrique est paramétré pour recevoir un Null - si tu envoies un Null pour la date.
Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te renvoie une alerte mais c'est bon.
en faisant :
set GLOBAL sql_mode='ANSI';
celà doit passer (à condition que tu ais les droits ;-))
Sinon au pire si ne marche toujours pas faire une colonne du type char et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu fais une fonction en sql qui copie ta colonne temporarire vers ta colonne date en convertissant explicitement ta chaine en date
Quelqu'un connaît-il le paramètre miracle qui va nous débloquer ? Merci d'avance.
Michel Fages
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
MiF
Daniel wrote:
Bonjour, "MiF" writes:
> Bonjour, > > Je migre actuellement de Sql Server vers MySQL une application dans > laquelle de cochonnes requêtes d'insertion ont été écrites en i nsérant > des chaines vides (='') à la place d'un NULL pour les champs date n on > renseignés. > > Si Sql Server supportait sans problème cet abus (il transforme > automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec > une date dont la valeur est vide. J'ai tenté d'utiliser les options > possibles de sql_mode, mais sans succès. > > Vu le volume de l'application, il paraît injouable de repasser chaque > requête pour la modifier adéquatement, et remplacer les '' par des > NULL.
Il n'y a pas de difficulté si : - ta rubrique est paramétré pour recevoir un Null - si tu envoies un Null pour la date.
Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te renvoie une alerte mais c'est bon.
en faisant :
set GLOBAL sql_mode='ANSI';
celà doit passer (à condition que tu ais les droits ;-))
Sinon au pire si ne marche toujours pas faire une colonne du type char et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu fais une fonction en sql qui copie ta colonne temporarire vers ta colonne date en convertissant explicitement ta chaine en date
Bonour Daniel,
J'ai déjà essayé le set GLOBAL sql_mode='ANSI'; avant de poster ici, sans succès. Je retiens ton idée de doubler les champs, si mon problème ne trouve pas d'autre solution.
Merci.
Michel Fages
Daniel wrote:
Bonjour,
"MiF" <michel.fages@gmail.com> writes:
> Bonjour,
>
> Je migre actuellement de Sql Server vers MySQL une application dans
> laquelle de cochonnes requêtes d'insertion ont été écrites en i nsérant
> des chaines vides (='') à la place d'un NULL pour les champs date n on
> renseignés.
>
> Si Sql Server supportait sans problème cet abus (il transforme
> automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec
> une date dont la valeur est vide. J'ai tenté d'utiliser les options
> possibles de sql_mode, mais sans succès.
>
> Vu le volume de l'application, il paraît injouable de repasser chaque
> requête pour la modifier adéquatement, et remplacer les '' par des
> NULL.
Il n'y a pas de difficulté si :
- ta rubrique est paramétré pour recevoir un Null
- si tu envoies un Null pour la date.
Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te
renvoie une alerte mais c'est bon.
en faisant :
set GLOBAL sql_mode='ANSI';
celà doit passer (à condition que tu ais les droits ;-))
Sinon au pire si ne marche toujours pas faire une colonne du type char
et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu
fais une fonction en sql qui copie ta colonne temporarire vers ta
colonne date en convertissant explicitement ta chaine en date
Bonour Daniel,
J'ai déjà essayé le set GLOBAL sql_mode='ANSI'; avant de poster ici,
sans succès.
Je retiens ton idée de doubler les champs, si mon problème ne trouve
pas d'autre solution.
> Bonjour, > > Je migre actuellement de Sql Server vers MySQL une application dans > laquelle de cochonnes requêtes d'insertion ont été écrites en i nsérant > des chaines vides (='') à la place d'un NULL pour les champs date n on > renseignés. > > Si Sql Server supportait sans problème cet abus (il transforme > automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec > une date dont la valeur est vide. J'ai tenté d'utiliser les options > possibles de sql_mode, mais sans succès. > > Vu le volume de l'application, il paraît injouable de repasser chaque > requête pour la modifier adéquatement, et remplacer les '' par des > NULL.
Il n'y a pas de difficulté si : - ta rubrique est paramétré pour recevoir un Null - si tu envoies un Null pour la date.
Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te renvoie une alerte mais c'est bon.
en faisant :
set GLOBAL sql_mode='ANSI';
celà doit passer (à condition que tu ais les droits ;-))
Sinon au pire si ne marche toujours pas faire une colonne du type char et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu fais une fonction en sql qui copie ta colonne temporarire vers ta colonne date en convertissant explicitement ta chaine en date
Bonour Daniel,
J'ai déjà essayé le set GLOBAL sql_mode='ANSI'; avant de poster ici, sans succès. Je retiens ton idée de doubler les champs, si mon problème ne trouve pas d'autre solution.
Merci.
Michel Fages
Daniel
"MiF" writes:
Daniel wrote: > Bonjour, > "MiF" writes: > > > Bonjour, > > > > Je migre actuellement de Sql Server vers MySQL une application dans > > laquelle de cochonnes requêtes d'insertion ont été écrites en insérant > > des chaines vides (='') à la place d'un NULL pour les champs date non > > renseignés. > > > > Si Sql Server supportait sans problème cet abus (il transforme > > automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec > > une date dont la valeur est vide. J'ai tenté d'utiliser les options > > possibles de sql_mode, mais sans succès. > > > > Vu le volume de l'application, il paraît injouable de repasser chaq ue > > requête pour la modifier adéquatement, et remplacer les '' par des > > NULL. > > Il n'y a pas de difficulté si : > - ta rubrique est paramétré pour recevoir un Null > - si tu envoies un Null pour la date. > > Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te > renvoie une alerte mais c'est bon. > > en faisant : > > set GLOBAL sql_mode='ANSI'; > > celà doit passer (à condition que tu ais les droits ;-)) > > Pour plus d'info voir le lien > > http://dev.mysql.com/doc/refman/5.0/fr/server-sql-mode.html > > Sinon au pire si ne marche toujours pas faire une colonne du type char > et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu > fais une fonction en sql qui copie ta colonne temporarire vers ta > colonne date en convertissant explicitement ta chaine en date >
Bonour Daniel,
J'ai déjà essayé le set GLOBAL sql_mode='ANSI'; avant de poster i ci, sans succès.
Que donne une commande Insert avec le frontal de Mysql? Car si on est pas en mode ANSI avec une v5.0.15 tu as un retour erreur, sauf si tu passes avec un Null.
Assure toi que tu as les droits pour changer le sql_mode,
Ce que je te dis je l'ai testé sous un frontal, mais pas en WD direct
Autre point, quelle est l'erreur renvoyée si ta commande ne passe pas? Est ce que ta date n'est pas dans un index, car dans ce cas vire les champs date des index...
De toute façon si tu fais une copie SQLserver vers MySQL tu as tout intéret à faire les index lorsque tu as tout retranscrit.
Voilà...
Je retiens ton idée de doubler les champs, si mon problème ne trouve pas d'autre solution.
Merci.
Michel Fages
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
"MiF" <michel.fages@gmail.com> writes:
Daniel wrote:
> Bonjour,
> "MiF" <michel.fages@gmail.com> writes:
>
> > Bonjour,
> >
> > Je migre actuellement de Sql Server vers MySQL une application dans
> > laquelle de cochonnes requêtes d'insertion ont été écrites en insérant
> > des chaines vides (='') à la place d'un NULL pour les champs date non
> > renseignés.
> >
> > Si Sql Server supportait sans problème cet abus (il transforme
> > automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec
> > une date dont la valeur est vide. J'ai tenté d'utiliser les options
> > possibles de sql_mode, mais sans succès.
> >
> > Vu le volume de l'application, il paraît injouable de repasser chaq ue
> > requête pour la modifier adéquatement, et remplacer les '' par des
> > NULL.
>
> Il n'y a pas de difficulté si :
> - ta rubrique est paramétré pour recevoir un Null
> - si tu envoies un Null pour la date.
>
> Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te
> renvoie une alerte mais c'est bon.
>
> en faisant :
>
> set GLOBAL sql_mode='ANSI';
>
> celà doit passer (à condition que tu ais les droits ;-))
>
> Pour plus d'info voir le lien
>
> http://dev.mysql.com/doc/refman/5.0/fr/server-sql-mode.html
>
> Sinon au pire si ne marche toujours pas faire une colonne du type char
> et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu
> fais une fonction en sql qui copie ta colonne temporarire vers ta
> colonne date en convertissant explicitement ta chaine en date
>
Bonour Daniel,
J'ai déjà essayé le set GLOBAL sql_mode='ANSI'; avant de poster i ci,
sans succès.
Que donne une commande Insert avec le frontal de Mysql? Car si on est
pas en mode ANSI avec une v5.0.15 tu as un retour erreur, sauf si tu
passes avec un Null.
Assure toi que tu as les droits pour changer le sql_mode,
Ce que je te dis je l'ai testé sous un frontal, mais pas en WD direct
Autre point, quelle est l'erreur renvoyée si ta commande ne passe pas?
Est ce que ta date n'est pas dans un index, car dans ce cas vire les
champs date des index...
De toute façon si tu fais une copie SQLserver vers MySQL tu as tout
intéret à faire les index lorsque tu as tout retranscrit.
Voilà...
Je retiens ton idée de doubler les champs, si mon problème ne trouve
pas d'autre solution.
Merci.
Michel Fages
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Daniel wrote: > Bonjour, > "MiF" writes: > > > Bonjour, > > > > Je migre actuellement de Sql Server vers MySQL une application dans > > laquelle de cochonnes requêtes d'insertion ont été écrites en insérant > > des chaines vides (='') à la place d'un NULL pour les champs date non > > renseignés. > > > > Si Sql Server supportait sans problème cet abus (il transforme > > automatiquement en 01/01/1900), MySQL 5.0 refuse toute insertion avec > > une date dont la valeur est vide. J'ai tenté d'utiliser les options > > possibles de sql_mode, mais sans succès. > > > > Vu le volume de l'application, il paraît injouable de repasser chaq ue > > requête pour la modifier adéquatement, et remplacer les '' par des > > NULL. > > Il n'y a pas de difficulté si : > - ta rubrique est paramétré pour recevoir un Null > - si tu envoies un Null pour la date. > > Toutefois celà est Ok avec date='' si tu passes en mode ANSI, il te > renvoie une alerte mais c'est bon. > > en faisant : > > set GLOBAL sql_mode='ANSI'; > > celà doit passer (à condition que tu ais les droits ;-)) > > Pour plus d'info voir le lien > > http://dev.mysql.com/doc/refman/5.0/fr/server-sql-mode.html > > Sinon au pire si ne marche toujours pas faire une colonne du type char > et tu écris tes dates de SQLserver dans cette colonne, et ensuite tu > fais une fonction en sql qui copie ta colonne temporarire vers ta > colonne date en convertissant explicitement ta chaine en date >
Bonour Daniel,
J'ai déjà essayé le set GLOBAL sql_mode='ANSI'; avant de poster i ci, sans succès.
Que donne une commande Insert avec le frontal de Mysql? Car si on est pas en mode ANSI avec une v5.0.15 tu as un retour erreur, sauf si tu passes avec un Null.
Assure toi que tu as les droits pour changer le sql_mode,
Ce que je te dis je l'ai testé sous un frontal, mais pas en WD direct
Autre point, quelle est l'erreur renvoyée si ta commande ne passe pas? Est ce que ta date n'est pas dans un index, car dans ce cas vire les champs date des index...
De toute façon si tu fais une copie SQLserver vers MySQL tu as tout intéret à faire les index lorsque tu as tout retranscrit.
Voilà...
Je retiens ton idée de doubler les champs, si mon problème ne trouve pas d'autre solution.
Merci.
Michel Fages
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
