Je rencontre actuellement un phénomène plutôt bizarre lorsque j'enregistre
une date dans une table Access à l'aide d'ADO. Je m'explique. Je tente
d'ajouter une ligne dans une table à l'aide d'une requête Insert, tout se
passe bien, seulement dans cette table j'ai un champ date et celui-ci ne
m'enregistre pas la date courante comme il devrait.
Par exemple ma requête ressemble à ceci
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, " & Date & ")"
J'ai également essayer de formater ma date en faisant Format$(Date,
"YYYY/MM/DD") mais rien d'y change. Lorsque je vais voir dans Access, ma
date ressemble plutôt à 1889-10-25 alors qu'elle aura dû être 2003-12-03.
Par contre si je change de méthode et que je fais
"SELECT * FROM TABLE1"
que j'utilise un recordset pour mettre ma table à jour de cette façon
rs.AddNew
rs!Champ1 = 10
rs!Champ2 = Date
rs.Update
Alors à ce moment quand je vais voir dans Access, ma date est bien
enregistré dans le bon format 2003-12-03.
Pourquoi ce phénomène se produit-il ? Pourtant Date retourne toujours la
même chose soit la date actuel dans un format selon les paramètres
régionaux.
Comme de raison, je peux m'accommoder de la dernière solution, mais je
préfèrerais grandement utiliser une requête Insert plutôt qu'un Select et
d'un AddNew. Y a-t-il donc un moyen d'effectuer mes enregistrements avec
Insert en ayant ma date dans le bon format?
Si quelqu'un connaît la solution à ce problème, merci de m'en faire part.
Soit mettre ta date entre appostrophe, la passer comme une string...
"Denis P" a écrit dans le message de news:
Bonjour tout le monde,
Je rencontre actuellement un phénomène plutôt bizarre lorsque j'enregistre une date dans une table Access à l'aide d'ADO. Je m'explique. Je tente d'ajouter une ligne dans une table à l'aide d'une requête Insert, tout se passe bien, seulement dans cette table j'ai un champ date et celui-ci ne m'enregistre pas la date courante comme il devrait.
Par exemple ma requête ressemble à ceci
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, " & Date & ")"
J'ai également essayer de formater ma date en faisant Format$(Date, "YYYY/MM/DD") mais rien d'y change. Lorsque je vais voir dans Access, ma date ressemble plutôt à 1889-10-25 alors qu'elle aura dû être 2003-12-03.
Par contre si je change de méthode et que je fais
"SELECT * FROM TABLE1"
que j'utilise un recordset pour mettre ma table à jour de cette façon
rs.AddNew rs!Champ1 = 10 rs!Champ2 = Date rs.Update
Alors à ce moment quand je vais voir dans Access, ma date est bien enregistré dans le bon format 2003-12-03.
Pourquoi ce phénomène se produit-il ? Pourtant Date retourne toujours la même chose soit la date actuel dans un format selon les paramètres régionaux.
Comme de raison, je peux m'accommoder de la dernière solution, mais je préfèrerais grandement utiliser une requête Insert plutôt qu'un Select et d'un AddNew. Y a-t-il donc un moyen d'effectuer mes enregistrements avec Insert en ayant ma date dans le bon format?
Si quelqu'un connaît la solution à ce problème, merci de m'en faire part.
Denis P
Ok, as-tu essayer d'entrer ta date de cette façon? :
Soit mettre ta date entre appostrophe, la passer comme une string...
"Denis P" <denispronovostNospam@sympatico.ca> a écrit dans le message de
news:u4CJg1buDHA.1888@TK2MSFTNGP10.phx.gbl...
Bonjour tout le monde,
Je rencontre actuellement un phénomène plutôt bizarre lorsque j'enregistre
une date dans une table Access à l'aide d'ADO. Je m'explique. Je tente
d'ajouter une ligne dans une table à l'aide d'une requête Insert, tout se
passe bien, seulement dans cette table j'ai un champ date et celui-ci ne
m'enregistre pas la date courante comme il devrait.
Par exemple ma requête ressemble à ceci
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, " & Date & ")"
J'ai également essayer de formater ma date en faisant Format$(Date,
"YYYY/MM/DD") mais rien d'y change. Lorsque je vais voir dans Access, ma
date ressemble plutôt à 1889-10-25 alors qu'elle aura dû être 2003-12-03.
Par contre si je change de méthode et que je fais
"SELECT * FROM TABLE1"
que j'utilise un recordset pour mettre ma table à jour de cette façon
rs.AddNew
rs!Champ1 = 10
rs!Champ2 = Date
rs.Update
Alors à ce moment quand je vais voir dans Access, ma date est bien
enregistré dans le bon format 2003-12-03.
Pourquoi ce phénomène se produit-il ? Pourtant Date retourne toujours la
même chose soit la date actuel dans un format selon les paramètres
régionaux.
Comme de raison, je peux m'accommoder de la dernière solution, mais je
préfèrerais grandement utiliser une requête Insert plutôt qu'un Select et
d'un AddNew. Y a-t-il donc un moyen d'effectuer mes enregistrements avec
Insert en ayant ma date dans le bon format?
Si quelqu'un connaît la solution à ce problème, merci de m'en faire part.
Soit mettre ta date entre appostrophe, la passer comme une string...
"Denis P" a écrit dans le message de news:
Bonjour tout le monde,
Je rencontre actuellement un phénomène plutôt bizarre lorsque j'enregistre une date dans une table Access à l'aide d'ADO. Je m'explique. Je tente d'ajouter une ligne dans une table à l'aide d'une requête Insert, tout se passe bien, seulement dans cette table j'ai un champ date et celui-ci ne m'enregistre pas la date courante comme il devrait.
Par exemple ma requête ressemble à ceci
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, " & Date & ")"
J'ai également essayer de formater ma date en faisant Format$(Date, "YYYY/MM/DD") mais rien d'y change. Lorsque je vais voir dans Access, ma date ressemble plutôt à 1889-10-25 alors qu'elle aura dû être 2003-12-03.
Par contre si je change de méthode et que je fais
"SELECT * FROM TABLE1"
que j'utilise un recordset pour mettre ma table à jour de cette façon
rs.AddNew rs!Champ1 = 10 rs!Champ2 = Date rs.Update
Alors à ce moment quand je vais voir dans Access, ma date est bien enregistré dans le bon format 2003-12-03.
Pourquoi ce phénomène se produit-il ? Pourtant Date retourne toujours la même chose soit la date actuel dans un format selon les paramètres régionaux.
Comme de raison, je peux m'accommoder de la dernière solution, mais je préfèrerais grandement utiliser une requête Insert plutôt qu'un Select et d'un AddNew. Y a-t-il donc un moyen d'effectuer mes enregistrements avec Insert en ayant ma date dans le bon format?
Si quelqu'un connaît la solution à ce problème, merci de m'en faire part.
Denis P
Zoury
Salut Dominic, salut Denis! :O)
si le champs est de type date ça passera peut-être pas... (sous SQL Server du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL..
quelque chose comme : '*** sQuery = "insert into table1(champ1, champ2) values('test', cast('" & Now & "' as datetime))" '***
un autre bon truc éviter les problèmes de format de date, c'est de passer la valeur en nombre de jour.
si tu converti une date en Single ou en Double, la partie entière te renvoi le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir cette valeur du côté SQL..
quelque chose comme : '*** sQuery = "insert into table1(champ1, champ2) values('test', cast(" & CDbl(Now) & " as datetime))" '***
Merci de poster les réponses au groupe afin d'en faire profiter à tous
Salut Dominic, salut Denis! :O)
si le champs est de type date ça passera peut-être pas... (sous SQL Server
du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL..
quelque chose comme :
'***
sQuery = "insert into table1(champ1, champ2) values('test', cast('" &
Now & "' as datetime))"
'***
un autre bon truc éviter les problèmes de format de date, c'est de passer la
valeur en nombre de jour.
si tu converti une date en Single ou en Double, la partie entière te renvoi
le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient
l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir cette
valeur du côté SQL..
quelque chose comme :
'***
sQuery = "insert into table1(champ1, champ2) values('test', cast(" &
CDbl(Now) & " as datetime))"
'***
si le champs est de type date ça passera peut-être pas... (sous SQL Server du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL..
quelque chose comme : '*** sQuery = "insert into table1(champ1, champ2) values('test', cast('" & Now & "' as datetime))" '***
un autre bon truc éviter les problèmes de format de date, c'est de passer la valeur en nombre de jour.
si tu converti une date en Single ou en Double, la partie entière te renvoi le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir cette valeur du côté SQL..
quelque chose comme : '*** sQuery = "insert into table1(champ1, champ2) values('test', cast(" & CDbl(Now) & " as datetime))" '***
Merci de poster les réponses au groupe afin d'en faire profiter à tous
Denis P
Merci Yanick pour le truc, je vais m'en souvenir pour SQL Server, mais le problème c'est que là je travaille avec une base Access et malheureusement à moins que je me trompe Cast ne fonctionne pas sous Access. Mais je comprend toujours pas plus pourquoi Date s'inscrit de façon différente selon qu'il soit dans un Insert ou un Update.
J'ai bien l'impression que je vais devoir me contenter de mon recordset avec un Update si je veux avoir le bon format de date. Ce que je déplore le plus dans cette façon de fonctionner, c'est que cette façon tôt ou tard ralentira le programme et augmentera considérablement le trafic sur le réseau. Avec un Insert le programme envoie seulement les données vers Access, alors qu'avec un Update je dois d'abord récupérer la table pour ensuite lui passer le Update. Donc plus la table augmentera en volume et plus de données devront passées de Access au programme, et cela absolument pour rien, sauf pour y retourner un enregistrement.
Il me vient donc une question à l'esprit. Actuellement pour effectuer mon Update à partir de mon recordset, je sélectionne la table en entier. Alors pour éviter un transfert de données inutiliment, sera-t-il possible d'effectuer une requête qui me ramènrait seulement le dernier enregistrement de ma table et de pouvoir y effectuer un Update quand même.
Comme de raison, je vais tester cette solution, mais si quelqu'un arrive à me trouver la solution pour que je puisse utiliser une requête Insert, j'en serais ravi.
Merci encore de vos suggestions en espérant que quelqu'un pourra m'expliquer cet étrange phénomène de format de date.
Denis P
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news:
Salut Dominic, salut Denis! :O)
si le champs est de type date ça passera peut-être pas... (sous SQL Server du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL..
quelque chose comme : '*** sQuery = "insert into table1(champ1, champ2) values('test', cast('" & Now & "' as datetime))" '***
un autre bon truc éviter les problèmes de format de date, c'est de passer
la
valeur en nombre de jour.
si tu converti une date en Single ou en Double, la partie entière te
renvoi
le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir
cette
valeur du côté SQL..
quelque chose comme : '*** sQuery = "insert into table1(champ1, champ2) values('test', cast(" & CDbl(Now) & " as datetime))" '***
Merci de poster les réponses au groupe afin d'en faire profiter à tous
Merci Yanick pour le truc, je vais m'en souvenir pour SQL Server, mais le
problème c'est que là je travaille avec une base Access et malheureusement à
moins que je me trompe Cast ne fonctionne pas sous Access. Mais je comprend
toujours pas plus pourquoi Date s'inscrit de façon différente selon qu'il
soit dans un Insert ou un Update.
J'ai bien l'impression que je vais devoir me contenter de mon recordset avec
un Update si je veux avoir le bon format de date. Ce que je déplore le plus
dans cette façon de fonctionner, c'est que cette façon tôt ou tard ralentira
le programme et augmentera considérablement le trafic sur le réseau. Avec
un Insert le programme envoie seulement les données vers Access, alors
qu'avec un Update je dois d'abord récupérer la table pour ensuite lui passer
le Update. Donc plus la table augmentera en volume et plus de données
devront passées de Access au programme, et cela absolument pour rien, sauf
pour y retourner un enregistrement.
Il me vient donc une question à l'esprit. Actuellement pour effectuer mon
Update à partir de mon recordset, je sélectionne la table en entier. Alors
pour éviter un transfert de données inutiliment, sera-t-il possible
d'effectuer une requête qui me ramènrait seulement le dernier enregistrement
de ma table et de pouvoir y effectuer un Update quand même.
Comme de raison, je vais tester cette solution, mais si quelqu'un arrive à
me trouver la solution pour que je puisse utiliser une requête Insert, j'en
serais ravi.
Merci encore de vos suggestions en espérant que quelqu'un pourra m'expliquer
cet étrange phénomène de format de date.
Denis P
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de
news:OKqrNfduDHA.1740@TK2MSFTNGP12.phx.gbl...
Salut Dominic, salut Denis! :O)
si le champs est de type date ça passera peut-être pas... (sous SQL Server
du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL..
quelque chose comme :
'***
sQuery = "insert into table1(champ1, champ2) values('test', cast('" &
Now & "' as datetime))"
'***
un autre bon truc éviter les problèmes de format de date, c'est de passer
la
valeur en nombre de jour.
si tu converti une date en Single ou en Double, la partie entière te
renvoi
le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient
l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir
cette
valeur du côté SQL..
quelque chose comme :
'***
sQuery = "insert into table1(champ1, champ2) values('test', cast(" &
CDbl(Now) & " as datetime))"
'***
Merci Yanick pour le truc, je vais m'en souvenir pour SQL Server, mais le problème c'est que là je travaille avec une base Access et malheureusement à moins que je me trompe Cast ne fonctionne pas sous Access. Mais je comprend toujours pas plus pourquoi Date s'inscrit de façon différente selon qu'il soit dans un Insert ou un Update.
J'ai bien l'impression que je vais devoir me contenter de mon recordset avec un Update si je veux avoir le bon format de date. Ce que je déplore le plus dans cette façon de fonctionner, c'est que cette façon tôt ou tard ralentira le programme et augmentera considérablement le trafic sur le réseau. Avec un Insert le programme envoie seulement les données vers Access, alors qu'avec un Update je dois d'abord récupérer la table pour ensuite lui passer le Update. Donc plus la table augmentera en volume et plus de données devront passées de Access au programme, et cela absolument pour rien, sauf pour y retourner un enregistrement.
Il me vient donc une question à l'esprit. Actuellement pour effectuer mon Update à partir de mon recordset, je sélectionne la table en entier. Alors pour éviter un transfert de données inutiliment, sera-t-il possible d'effectuer une requête qui me ramènrait seulement le dernier enregistrement de ma table et de pouvoir y effectuer un Update quand même.
Comme de raison, je vais tester cette solution, mais si quelqu'un arrive à me trouver la solution pour que je puisse utiliser une requête Insert, j'en serais ravi.
Merci encore de vos suggestions en espérant que quelqu'un pourra m'expliquer cet étrange phénomène de format de date.
Denis P
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news:
Salut Dominic, salut Denis! :O)
si le champs est de type date ça passera peut-être pas... (sous SQL Server du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL..
quelque chose comme : '*** sQuery = "insert into table1(champ1, champ2) values('test', cast('" & Now & "' as datetime))" '***
un autre bon truc éviter les problèmes de format de date, c'est de passer
la
valeur en nombre de jour.
si tu converti une date en Single ou en Double, la partie entière te
renvoi
le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir
cette
valeur du côté SQL..
quelque chose comme : '*** sQuery = "insert into table1(champ1, champ2) values('test', cast(" & CDbl(Now) & " as datetime))" '***
Merci de poster les réponses au groupe afin d'en faire profiter à tous
+The_Taco+
Ah oui? je ne savais pas qu'il fallait des # pour la date en access... Je croyais que c'était pareil comme SQL Server, soit les ' de chauqe côté de la date..
J'en prend note!
"Denis P" a écrit dans le message de news:
D'accord je viens de trouver la solution.
Une erreur stupide à laquelle j'aurais dû penser avant.
je faisais
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, " & Date & ")" et bien il fallait simplement que je fasse plutôt
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, #" & Date & "#)"
les chers dièses (#) que l'on doit mettre avant une date
Merci tout de même de vous être pencher sur mon problème.
@ +
Denis P
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news: > Salut Dominic, salut Denis! :O) > > > si le champs est de type date ça passera peut-être pas... (sous SQL
Server
> du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL.. > > quelque chose comme : > '*** > sQuery = "insert into table1(champ1, champ2) values('test', cast('"
&
> Now & "' as datetime))" > '*** > > > > un autre bon truc éviter les problèmes de format de date, c'est de
passer
la > valeur en nombre de jour. > > si tu converti une date en Single ou en Double, la partie entière te renvoi > le nombre de jour depuis 30 Décembre 1899 et a la partie décimal
contient
> l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir cette > valeur du côté SQL.. > > quelque chose comme : > '*** > sQuery = "insert into table1(champ1, champ2) values('test', cast(" & > CDbl(Now) & " as datetime))" > '*** > > -- > Cordialement > Yanick Lefebvre - MVP pour Visual Basic > http://faq.vb.free.fr/?rubrique=0 - http://www.mvps.org/vbnet/ > http://www.mentalis.org/agnet/apiguide.shtml - http://www.mztools.com/ > > Merci de poster les réponses au groupe afin d'en faire profiter à tous > >
Ah oui? je ne savais pas qu'il fallait des # pour la date en access... Je
croyais que c'était pareil comme SQL Server, soit les ' de chauqe côté de la
date..
J'en prend note!
"Denis P" <denispronovostNospam@sympatico.ca> a écrit dans le message de
news:O7r2GHfuDHA.1764@TK2MSFTNGP10.phx.gbl...
D'accord je viens de trouver la solution.
Une erreur stupide à laquelle j'aurais dû penser avant.
je faisais
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, " & Date & ")"
et bien il fallait simplement que je fasse plutôt
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, #" & Date & "#)"
les chers dièses (#) que l'on doit mettre avant une date
Merci tout de même de vous être pencher sur mon problème.
@ +
Denis P
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de
news:OKqrNfduDHA.1740@TK2MSFTNGP12.phx.gbl...
> Salut Dominic, salut Denis! :O)
>
>
> si le champs est de type date ça passera peut-être pas... (sous SQL
Server
> du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL..
>
> quelque chose comme :
> '***
> sQuery = "insert into table1(champ1, champ2) values('test', cast('"
&
> Now & "' as datetime))"
> '***
>
>
>
> un autre bon truc éviter les problèmes de format de date, c'est de
passer
la
> valeur en nombre de jour.
>
> si tu converti une date en Single ou en Double, la partie entière te
renvoi
> le nombre de jour depuis 30 Décembre 1899 et a la partie décimal
contient
> l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir
cette
> valeur du côté SQL..
>
> quelque chose comme :
> '***
> sQuery = "insert into table1(champ1, champ2) values('test', cast(" &
> CDbl(Now) & " as datetime))"
> '***
>
> --
> Cordialement
> Yanick Lefebvre - MVP pour Visual Basic
> http://faq.vb.free.fr/?rubrique=0 - http://www.mvps.org/vbnet/
> http://www.mentalis.org/agnet/apiguide.shtml - http://www.mztools.com/
>
> Merci de poster les réponses au groupe afin d'en faire profiter à tous
>
>
Ah oui? je ne savais pas qu'il fallait des # pour la date en access... Je croyais que c'était pareil comme SQL Server, soit les ' de chauqe côté de la date..
J'en prend note!
"Denis P" a écrit dans le message de news:
D'accord je viens de trouver la solution.
Une erreur stupide à laquelle j'aurais dû penser avant.
je faisais
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, " & Date & ")" et bien il fallait simplement que je fasse plutôt
"INSERT INTO TABLE1 (Champ1, Champ2) Values (10, #" & Date & "#)"
les chers dièses (#) que l'on doit mettre avant une date
Merci tout de même de vous être pencher sur mon problème.
@ +
Denis P
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news: > Salut Dominic, salut Denis! :O) > > > si le champs est de type date ça passera peut-être pas... (sous SQL
Server
> du moins ça ne passe pas..).. il faudra la re"caster" du côté SQL.. > > quelque chose comme : > '*** > sQuery = "insert into table1(champ1, champ2) values('test', cast('"
&
> Now & "' as datetime))" > '*** > > > > un autre bon truc éviter les problèmes de format de date, c'est de
passer
la > valeur en nombre de jour. > > si tu converti une date en Single ou en Double, la partie entière te renvoi > le nombre de jour depuis 30 Décembre 1899 et a la partie décimal
contient
> l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir cette > valeur du côté SQL.. > > quelque chose comme : > '*** > sQuery = "insert into table1(champ1, champ2) values('test', cast(" & > CDbl(Now) & " as datetime))" > '*** > > -- > Cordialement > Yanick Lefebvre - MVP pour Visual Basic > http://faq.vb.free.fr/?rubrique=0 - http://www.mvps.org/vbnet/ > http://www.mentalis.org/agnet/apiguide.shtml - http://www.mztools.com/ > > Merci de poster les réponses au groupe afin d'en faire profiter à tous > >
Zoury
aaaaaaaaaarrrrggghhhhhh!! j'l'oublie tout le temps ça!! Merci du rappelle! ;O)
Merci de poster les réponses au groupe afin d'en faire profiter à tous
Zoury
> un autre bon truc éviter les problèmes de format de date, c'est de passer
la
valeur en nombre de jour. si tu converti une date en Single ou en Double, la partie entière te
renvoi
le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir
cette
valeur du côté SQL..
Je viens de faire une découverte assez étonnante à ce sujet..
Le format de Date de Visual Studio (6.0 ou .NET) te renvoi le nombre de jours écoulé depuis le 30 décembre 1899 alors que SQL Server renvoit le nombre de jour écoulé depuis le 1 janvier 1900... il faut donc enlever 2 au nombre avant de le reconvertir dans le SQL afin d'avoir la même valeur dans les 2 systèmes... :O/
Maintenant la nouvelle question est.. mais à quoi les concepteurs ont-ils pensé??? ;O)
Merci de poster les réponses au groupe afin d'en faire profiter à tous
> un autre bon truc éviter les problèmes de format de date, c'est de passer
la
valeur en nombre de jour.
si tu converti une date en Single ou en Double, la partie entière te
renvoi
le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient
l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir
cette
valeur du côté SQL..
Je viens de faire une découverte assez étonnante à ce sujet..
Le format de Date de Visual Studio (6.0 ou .NET) te renvoi le nombre de
jours écoulé depuis le 30 décembre 1899 alors que SQL Server renvoit le
nombre de jour écoulé depuis le 1 janvier 1900... il faut donc enlever 2 au
nombre avant de le reconvertir dans le SQL afin d'avoir la même valeur dans
les 2 systèmes... :O/
Maintenant la nouvelle question est.. mais à quoi les concepteurs ont-ils
pensé??? ;O)
> un autre bon truc éviter les problèmes de format de date, c'est de passer
la
valeur en nombre de jour. si tu converti une date en Single ou en Double, la partie entière te
renvoi
le nombre de jour depuis 30 Décembre 1899 et a la partie décimal contient l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir
cette
valeur du côté SQL..
Je viens de faire une découverte assez étonnante à ce sujet..
Le format de Date de Visual Studio (6.0 ou .NET) te renvoi le nombre de jours écoulé depuis le 30 décembre 1899 alors que SQL Server renvoit le nombre de jour écoulé depuis le 1 janvier 1900... il faut donc enlever 2 au nombre avant de le reconvertir dans le SQL afin d'avoir la même valeur dans les 2 systèmes... :O/
Maintenant la nouvelle question est.. mais à quoi les concepteurs ont-ils pensé??? ;O)
Merci de poster les réponses au groupe afin d'en faire profiter à tous
+The_Taco+
Il y a eu une chicane dans 2 départements. La conclusion: chacun a fait à sa tête :)
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news:
> un autre bon truc éviter les problèmes de format de date, c'est de
passer
la > valeur en nombre de jour. > si tu converti une date en Single ou en Double, la partie entière te renvoi > le nombre de jour depuis 30 Décembre 1899 et a la partie décimal
contient
> l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir cette > valeur du côté SQL..
Je viens de faire une découverte assez étonnante à ce sujet..
Le format de Date de Visual Studio (6.0 ou .NET) te renvoi le nombre de jours écoulé depuis le 30 décembre 1899 alors que SQL Server renvoit le nombre de jour écoulé depuis le 1 janvier 1900... il faut donc enlever 2
au
nombre avant de le reconvertir dans le SQL afin d'avoir la même valeur
dans
les 2 systèmes... :O/
Maintenant la nouvelle question est.. mais à quoi les concepteurs ont-ils pensé??? ;O)
Merci de poster les réponses au groupe afin d'en faire profiter à tous
Il y a eu une chicane dans 2 départements. La conclusion: chacun a fait à sa
tête :)
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de
news:uuvrSb2uDHA.2368@TK2MSFTNGP09.phx.gbl...
> un autre bon truc éviter les problèmes de format de date, c'est de
passer
la
> valeur en nombre de jour.
> si tu converti une date en Single ou en Double, la partie entière te
renvoi
> le nombre de jour depuis 30 Décembre 1899 et a la partie décimal
contient
> l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir
cette
> valeur du côté SQL..
Je viens de faire une découverte assez étonnante à ce sujet..
Le format de Date de Visual Studio (6.0 ou .NET) te renvoi le nombre de
jours écoulé depuis le 30 décembre 1899 alors que SQL Server renvoit le
nombre de jour écoulé depuis le 1 janvier 1900... il faut donc enlever 2
au
nombre avant de le reconvertir dans le SQL afin d'avoir la même valeur
dans
les 2 systèmes... :O/
Maintenant la nouvelle question est.. mais à quoi les concepteurs ont-ils
pensé??? ;O)
Il y a eu une chicane dans 2 départements. La conclusion: chacun a fait à sa tête :)
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news:
> un autre bon truc éviter les problèmes de format de date, c'est de
passer
la > valeur en nombre de jour. > si tu converti une date en Single ou en Double, la partie entière te renvoi > le nombre de jour depuis 30 Décembre 1899 et a la partie décimal
contient
> l'heure (0 pour minuit, 0,5 pour midi..). Tu pourrais donc reconvertir cette > valeur du côté SQL..
Je viens de faire une découverte assez étonnante à ce sujet..
Le format de Date de Visual Studio (6.0 ou .NET) te renvoi le nombre de jours écoulé depuis le 30 décembre 1899 alors que SQL Server renvoit le nombre de jour écoulé depuis le 1 janvier 1900... il faut donc enlever 2
au
nombre avant de le reconvertir dans le SQL afin d'avoir la même valeur
dans
les 2 systèmes... :O/
Maintenant la nouvelle question est.. mais à quoi les concepteurs ont-ils pensé??? ;O)
