11
votes

SQL Server DateTime Problèmes. Américain contre Britannique?

Sur mon test DB, les dates sont affichées dans un format DD / mm / aaaa. En affiché, je veux dire lorsque vous cliquez avec le bouton droit de la souris, ouvrez la table dans Management Studio, les données renvoyées sont affichées dans un format DD / MM / AAAA.

La chose drôle est, lorsque j'écris T-SQL pour récupérer des enregistrements, je dois saisir un format MM / DD / AAAA pour récupérer les bonnes données. Est là quand même je peux l'aligner sur un format DD / mm / aaaa?


0 commentaires

7 Réponses :


12
votes

Vous pouvez utiliser Définir la langue pour choisir le format de date que SQL Serveur s'attend à ce que em> strong> dans les requêtes (je pense que Management Studio utilise les paramètres régionaux de l'ordinateur client à des fins d'affichage, pas sûr de). Cependant, je suggère de transmettre des valeurs à l'aide de paramètres au lieu de les intégrer à la relève de la requête. Vous ne rencontrerez aucun problème si vous utilisez des paramètres. Tout est pris en charge.

declare @langid int = (select langid from syslanguages where name = 'british')
exec sp_configure 'default language', @langid
reconfigure with override


3 commentaires

C'est un grand mais je cherche une solution permanente plutôt qu'une solution de session.


Doux. FYI Le nom de table correct est SyS.SysLanguages. De plus, je viens de découvrir que vous pouvez modifier la langue par défaut sur un niveau utilisateur également en allant à la sécurité -> Connexion utilisateur -> Propriétés -> Langue. Merci pour ce Mehrdad


NAI: SysLangues seuls fonctionnera si vous êtes dans la base de données principale. Ajouter sys. à cette ligne a fait l'apparition des barres de défilement, alors je l'ai raccourci;)



4
votes

Personnellement, je toujours utilisez le format AAAA-MM-DD (ou YYYYMMDD) car ce n'est pas spécifique à la culture et, bien, je suppose que cela m'appelle parce qu'il est "logique" (surtout quand suivi d'une heure).

[Edit: Je parle simplement de ce que j'ai mis dans mes scripts SQL pour assurer la compatibilité quel que soit les paramètres du serveur, pas ce que SQL Server "s'affiche"]


1 commentaires

Comment fonctionne-t-on pour changer les défauts de requête T-SQL Datime à cela?



1
votes

Dans presque tous les cas, la bonne façon de résoudre ceci est simplement de ne jamais traiter la date comme une chaîne. Si vous passez dans un paramètre ou utilisez la valeur de la colonne (dactylographiée), la conversion le texte n'est tout simplement pas un facteur. En plus d'éviter le problème I18N, cela réduit également votre surface d'attaque d'injection. Et cela économise quelques cycles de processeur aussi ;-p

Si vous utilisez EXEC pour Dynamic SQL, cela devrait également être paramétré via sp_executeql . .


3 commentaires

Les dates sont stockées de manière acuellement stockée comme formats DateTime. Désolé si je n'étais pas clair.


J'ai supposé que; Mon point est que cela ne devrait pas matière comment le serveur veut les gérer comme texte si vous ne le faites tout simplement jamais (dans votre système) traiter comme texte.


Oh, c'est bien, j'obtiens ce que tu veux dire. Je les transmettais normalement sous forme de variables mais de bon avis néanmoins. Merci pour ça!



2
votes

Si vous passez dans DateTime dans le format xxx

par exemple xxx

Il n'y a jamais d'ambiguïté autour du mois et de la date et donc Vous ne devriez jamais avoir de problème


0 commentaires

1
votes

J'essaie d'utiliser la forme canonique ODBC d'une date dans la mesure du possible {d 'yyyy-mm-dd'} De cette façon, je sais comment SQL Server l'interprétera. Cela fonctionne à Tsql juste bien.


0 commentaires

3
votes

1
votes

ajoutez ceci à votre fichier web.config: xxx

ou vous pouvez ajouter cette instruction sur la page: xxx

< / p>

J'espère cette aide.


0 commentaires