SQL Server 2005 contre la confusion du format datetime ASP.net

Question

J'ai trouvé une question similaire sur le débordement de pile, mais elle n'a pas vraiment répondu à la question que j'ai. Je dois m'assurer que mon application asp.net met en forme la date jj/mm/aaaa de la même manière que SQL Server 2005.

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

merci

Answer 1

Lorsque vous obtenez une DateTime de la base de données, il devrait être dans un format non-culture (comme l'objet DateTime, en fonction du nombre de tiques depuis une certaine date). Ce n'est que lorsque vous convertissez cette valeur en une chaîne que vous devez vous intéresser à la culture. Dans ce cas, vous pouvez utiliser yourDateTimeValue.ToString ("jj/MM/aaaa", CultureInfo.InvariantCulture) pour vous assurer que les informations s'affichent correctement.

Answer 2

** Attention car les colonnes SQL DateTime sont non nulles et leur valeur minimale est 1/1/1753 tandis que .net DateTimes sont non nullable avec des valeurs minimales de 1/1/0001. **

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

i ripped off de ce http://bytes.com/forum/thread767920.html:

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

Answer 3

Eh bien, si vous conservez des champs datetime dans la BD, vous ne devriez pas vous en préoccuper.

Tant que vous gardez les dates dans l'application fortement typées (variables DateTime) et envoyez les dates à travers des instructions préparées avec DBParameter/SqlParameter, votre DB les prendra telles quelles.

Si vous utilisez des chaînes pour tenir vos dates dans le code, quelques moulages vous assurer d'envoyer 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 laid, mais nous espérons qu'il obtient le point à travers)

Answer 4

Je crois que si vous utilisez SqlParameters ADO.NET s'occupera du reste et vous n'avez pas à vous en préoccuper. En plus, c'est bon pour se défendre contre les attaques par Injection SQL aussi! :)

Answer 5

Comme d'autres l'ont mentionné, vous devriez être en mesure de stocker des dattes culturellement. Ce que je recommanderais, c'est que vous conserviez toutes vos heures en temps UTC standard. Dans SQL Server 2005 et versions antérieures, il n'existe aucun moyen de stocker des informations de fuseau horaire, mais si tout est stocké dans l'heure universelle, vous devez être OK car l'heure peut être convertie en heure locale plus tard.

SQL Server 2008 a certains types de données qui sont conscients des fuseaux horaires, et si vous utilisez .NET 3.5, il existe des outils pour aider à la gestion des fuseaux horaires/conversions.

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