Discussion :

[VITALTH]

Bonjour,
Il ne s'agit pas d'un problème mais du contournement d'un problème que j'ai déjà remarqué dans SQL Server/C# et que je vous propose et bien que ma solution marche si vous avez plus "élégant" je suis preneur.

La plupart des codes que je développe en ADO avec C# pour accès à une base SQL Server utilise le OleDb fournisseur en partie parce que j'utilise SSIS 2008R2 et que dans ces conditions, Ole Db est largement le meilleur fournisseur.
Très souvent il m'arrive d'utiliser les connecteurs SSIS et de ne pas me poser des questions pour l'accès à la BD mais il m'arrive de devoir faire des scripts complexes qui nécessite du code via ADO.

Il s'avère que j'utilise des tables de trace ou une datetime me permet de repérer les évenements. La précision à quelques millisecondes près me va bien.
Sauf que lorsque j'utilise DateTime.Now et que je le transfère en paramètre d'une requête préparée avec un OleDbType = OleDbType.Date je "perds" la précision des millisecondes à l'insertion dans la table.

J'ai beau avoir cherché en changeant le type en datetime2 mais rien n'y fait et comme je ne suis pas spécialement fan des timestamp (peut être à tors j'avoue), je ne savais pas quoi faire.
Alors j'ai eu l'idée non pas d'utiliser un OleDbType.Date comme paramètre mais un OleDbType.VarChar comme paramètre et mon DateTime.Now je l'ai transformé en : DateTime.Now.Millisecond.ToString().PadLeft(3,'0').
La solution fonctionne même si elle n'est pas très élégante.

[DotNetMatt]

Alors j'ai eu l'idée non pas d'utiliser un OleDbType.Date comme paramètre mais un OleDbType.VarChar comme paramètre et mon DateTime.Now je l'ai transformé en : DateTime.Now.Millisecond.ToString().PadLeft(3,'0').
La solution fonctionne même si elle n'est pas très élégante.

Il ne faut surtout pas tomber dans la facilité ! As-tu pensé aux problèmes de performances qui vont se présenter le jour où tu auras besoin de cette colonne dans tes requêtes ? As-tu aussi pensé au développeur qui viendra après toi et qui devra se débattre avec cette bouse ? (désolé pour le terme un peu cru, mais c'est le seul mot qui me vienne à l'esprit pour ce genre de rustines immondes )

Là tout de suite je n'ai pas de solution à te proposer, mais ca mérite de creuser un peu. Je vais essayer de regarder ca, mais pas avant la semaine prochaine car le week-end s'annonce chargé... Entre temps si d'autres ont des idées n'hésitez pas bien entendu

[VITALTH]

Il ne faut surtout pas tomber dans la facilité ! As-tu pensé aux problèmes de performances qui vont se présenter le jour où tu auras besoin de cette colonne dans tes requêtes ? As-tu aussi pensé au développeur qui viendra après toi et qui devra se débattre avec cette bouse ? (désolé pour le terme un peu cru, mais c'est le seul mot qui me vienne à l'esprit pour ce genre de rustines immondes )

Là tout de suite je n'ai pas de solution à te proposer, mais ca mérite de creuser un peu. Je vais essayer de regarder ca, mais pas avant la semaine prochaine car le week-end s'annonce chargé... Entre temps si d'autres ont des idées n'hésitez pas bien entendu

Je n'aime pas non plus ce code je l'avoue mais avant tout je souhaite mettre en place quelque chose qui marche mais je n'abandonnerais pas, pour autant, le sujet.
Pour répondre à tes question :
- Pour les performances, je ne suis pas sur que ce soit un problème : je rappelle que dans la base de données : le paramètre est bien enregistré en datetime (et non en varchar) (donc la sélection dans des requêtes type select ... where date > <Une date> fonctionne très bien, order by fonctionne bien également) : c'est la passage de paramètre à la requête préparée qui est en varchar.
- Pour ceux qui viendront après moi : j'ai documenté le source pour expliquer la raison de cette vérue. Mais de toute façon il y a un truc qui ne trompe pas quand on fait DateTime.Now.ToString() : les millisecondes sont à 0

En ayant un peu cherché sur Internet j'ai constaté ne pas être le seul avec ce genre de problème : certains vont même jusqu'à faire hériter la classe DateTime (j'ai testé mais le résultat n'est pas satisfaisant).