Confusion de format datetime entre SQL Server 2005 et ASP.net

Question

J'ai trouvé une question similaire sur le dépassement de capacité de la pile, mais cela ne répond pas vraiment à la question que j'ai. Je dois m'assurer que mon application asp.net formate la date jj / mm / aaaa de la même manière que mon serveur SQL Server 2005.

Comment puis-je vérifier que la culture de la date (si c'est ainsi qu'on l'appelle) du serveur correspond à la façon dont j'ai programmé mon application? Existe-t-il des paramètres de base de données et des paramètres de système d'exploitation spécifiques? Est-ce spécifique à une table? Je ne veux pas transposer mes jours et mes mois.

merci

Answer 1

Lorsque vous extrayez un DateTime de la base de données, vous devez utiliser un format non cultivé (comme l’objet DateTime, en fonction du nombre de ticks depuis une certaine date). Ce n'est que lorsque vous convertissez cette valeur en une chaîne que vous devez vous préoccuper de la culture. Dans ces cas, vous pouvez utiliser votreDateTimeValue.ToString ("jj / MM / aaaa", CultureInfo.InvariantCulture) pour vous assurer que les informations s'affichent correctement.

Answer 2

Je pense que si vous utilisez SqlParameters, ADO.NET se chargera du reste et vous n’aurez pas à vous en préoccuper. En plus, c'est bon pour se défendre contre les attaques par injection SQL! :)

Answer 3

** Attention, car les colonnes SQL DateTime ne sont pas nullables et que leur valeur minimale est 1/1/1753 alors que .net DateTimes ne le sont pas avec des valeurs min de 1/1/0001. **

Si vous extrayez des données d'une colonne DateTime réelle, par défaut, elles seront toujours dans le même format standard. Pour enregistrer les données dans la colonne, vous pouvez spécifier le SqlDbType.DateTime dans votre paramètre.

J'ai arraché ça de http://bytes.com/forum/thread767920.html:

com.Parameters.Add ("@ adate", SqlDbType.DateTime) .Value = DateTime.Now;

Answer 4

Eh bien, si vous conservez des champs de date / heure dans la base de données, vous ne devriez pas vous en inquiéter.

Tant que vous gardez les dates dans l'application fortement typées (variables DateTime) et les envoyez par le biais d'instructions préparées avec DBParameter / SqlParameter, votre base de données les prendra telles quelles.

Si vous utilisez des chaînes pour conserver vos dates dans le code, certains casts vous assureront que vous envoyez les bonnes valeurs:

string sqlCmd = @"SELECT *
   FROM MyTable
   WHERE MyDateField = CONVERT(datetime, '{0}', 101)";

// assuming myDateString is a string with a date in the local format
sqlCmd = string.Format(sqlCmd,
    Convert.ToDateTime(myDateString).ToString("yyyyMMdd"));

(le code est moche, mais j'espère qu'il fait passer le message)

Answer 5

Comme d'autres l'ont mentionné, vous devriez être en mesure de stocker les dates et heures culturellement. Ce que je recommanderais, c’est que vous stockiez l’ensemble de vos heures au format UTC. Dans SQL Server 2005 et les versions antérieures, il n’existait aucun moyen de stocker les informations de fuseau horaire, mais si tout est stocké à l’heure universelle, vous devriez être en mesure de l’utiliser car l’heure peut être convertie ultérieurement en heure locale.

SQL Server 2008 contient des types de données qui prennent en compte les fuseaux horaires. Si vous utilisez .NET 3.5, vous disposez d'outils pour vous aider dans la gestion / conversion des fuseaux horaires.

Gardez les heures au format universel. Cela fera toute la différence si vous devez travailler dans plusieurs fuseaux horaires.