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
Frédéric Queudret \(MS\)
Bonjour,
La différence de la milliseconde est dûe à la conversion du type System.DateTime (CLR) vers le type System.Data.SqlTypes.SqlDateTime (SQL). Si vous souhaitez éviter ce problème de conversion impliquant une précision amoindrie, vous pouvez utiliser directement le type SqlDateTime. Votre exemple avec mes modifications: DateTime now;
SqlParameter p;
now = DateTime.Now;
now = new DateTime(now.Year, now.Month, now.Day, 23, 59, 59, 999);
System.Data.SqlTypes.SqlDateTime conversionSql = new System.Data.SqlTypes.SqlDateTime(now);
La solution de contournement que j'ai trouvé est la suivante :
Il faut utiliser un autre constructeur de SqlDateTime comme ceci :
p.SqlValue = new SqlDateTime(now.Year, now.Month, now.Day, now.Hour, now.Minute, now.Second, now.Millisecond);
Est-ce que un MVP ou une personne de chez Microsoft puisse me confirmer que c'est un bug du Framework ?
En vous remerciant par avance...
Cordialement
-- Gilles TOURREAU Responsable informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Bonjour,
La différence de la milliseconde est dûe à la conversion du type
System.DateTime (CLR) vers le type System.Data.SqlTypes.SqlDateTime (SQL).
Si vous souhaitez éviter ce problème de conversion impliquant une précision
amoindrie, vous pouvez utiliser directement le type SqlDateTime.
Votre exemple avec mes modifications:
DateTime now;
SqlParameter p;
now = DateTime.Now;
now = new DateTime(now.Year, now.Month, now.Day, 23, 59, 59, 999);
System.Data.SqlTypes.SqlDateTime conversionSql = new
System.Data.SqlTypes.SqlDateTime(now);
La différence de la milliseconde est dûe à la conversion du type System.DateTime (CLR) vers le type System.Data.SqlTypes.SqlDateTime (SQL). Si vous souhaitez éviter ce problème de conversion impliquant une précision amoindrie, vous pouvez utiliser directement le type SqlDateTime. Votre exemple avec mes modifications: DateTime now;
SqlParameter p;
now = DateTime.Now;
now = new DateTime(now.Year, now.Month, now.Day, 23, 59, 59, 999);
System.Data.SqlTypes.SqlDateTime conversionSql = new System.Data.SqlTypes.SqlDateTime(now);
La solution de contournement que j'ai trouvé est la suivante :
Il faut utiliser un autre constructeur de SqlDateTime comme ceci :
p.SqlValue = new SqlDateTime(now.Year, now.Month, now.Day, now.Hour, now.Minute, now.Second, now.Millisecond);
Est-ce que un MVP ou une personne de chez Microsoft puisse me confirmer que c'est un bug du Framework ?
En vous remerciant par avance...
Cordialement
-- Gilles TOURREAU Responsable informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Patrice
C'est pas vraiment un bug. Le problème est que la précision des dates dans une base n'est pas forcément la même que celle utilisée côté client ce qui peut donc générer des arrondis (3,33 ms de précision pour les datetime SQLServer).
J'ai déjà vu par exemple du temps d'ADO des pbs de verrouillage optimiste causé par ce problème...
-- Patrice
"Gilles TOURREAU" a écrit dans le message de news:
Bonjour,
Je viens de trouver un Bug au niveau du .NET Framework avec les dates en utilisant l'accès natif SQL Server.
Voici l'exemple de code à tester :
using System; using System.Data.SqlClient;
namespace ConsoleApplication1 { class Program { static void Main(string[] args) { DateTime now; SqlParameter p;
now = DateTime.Now; now = new DateTime(now.Year, now.Month, now.Day, 23, 59, 59, 999);
p = new SqlParameter(); p.DbType = System.Data.DbType.DateTime; p.Value = now;
La solution de contournement que j'ai trouvé est la suivante :
Il faut utiliser un autre constructeur de SqlDateTime comme ceci :
p.SqlValue = new SqlDateTime(now.Year, now.Month, now.Day, now.Hour, now.Minute, now.Second, now.Millisecond);
Est-ce que un MVP ou une personne de chez Microsoft puisse me confirmer que c'est un bug du Framework ?
En vous remerciant par avance...
Cordialement
-- Gilles TOURREAU Responsable informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
C'est pas vraiment un bug. Le problème est que la précision des dates dans
une base n'est pas forcément la même que celle utilisée côté client ce qui
peut donc générer des arrondis (3,33 ms de précision pour les datetime
SQLServer).
J'ai déjà vu par exemple du temps d'ADO des pbs de verrouillage optimiste
causé par ce problème...
--
Patrice
"Gilles TOURREAU" <gilles.tourreau@pos.fr> a écrit dans le message de news:
mn.237f7d68e85bbc3b.52180@pos.fr...
Bonjour,
Je viens de trouver un Bug au niveau du .NET Framework avec les dates en
utilisant l'accès natif SQL Server.
Voici l'exemple de code à tester :
using System;
using System.Data.SqlClient;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
DateTime now;
SqlParameter p;
now = DateTime.Now;
now = new DateTime(now.Year, now.Month, now.Day, 23, 59, 59,
999);
p = new SqlParameter();
p.DbType = System.Data.DbType.DateTime;
p.Value = now;
C'est pas vraiment un bug. Le problème est que la précision des dates dans une base n'est pas forcément la même que celle utilisée côté client ce qui peut donc générer des arrondis (3,33 ms de précision pour les datetime SQLServer).
J'ai déjà vu par exemple du temps d'ADO des pbs de verrouillage optimiste causé par ce problème...
-- Patrice
"Gilles TOURREAU" a écrit dans le message de news:
Bonjour,
Je viens de trouver un Bug au niveau du .NET Framework avec les dates en utilisant l'accès natif SQL Server.
Voici l'exemple de code à tester :
using System; using System.Data.SqlClient;
namespace ConsoleApplication1 { class Program { static void Main(string[] args) { DateTime now; SqlParameter p;
now = DateTime.Now; now = new DateTime(now.Year, now.Month, now.Day, 23, 59, 59, 999);
p = new SqlParameter(); p.DbType = System.Data.DbType.DateTime; p.Value = now;