Problemy z Datetime serwera SQL. Amerykański kontra brytyjski?

Question

W mojej testowej bazie danych daty są wyświetlane w formacie DD/MM/RRRR. Po wyświetleniu mam na myśli, że po kliknięciu prawym przyciskiem myszy, otwórz tabelę w Management Studio, zwrócone dane są wyświetlane w formacie DD/MM/RRRR.

Zabawne jest to, że kiedy piszę T-SQL, aby pobierać rekordy, muszę wprowadzić format MM/DD/RRRR, aby odzyskać właściwe dane. Czy mimo to mogę dostosować to do formatu DD/MM/RRRR?

Answer 1

Można użyć SET LANGUAGE aby wybrać format daty, że SQL Server spodziewa w zapytaniach (myślę Management Studio korzysta z ustawień regionalnych komputera klienckiego do celów wystawowych, choć nie jestem pewien). Sugeruję jednak przekazywanie wartości za pomocą parametrów zamiast osadzania ich w zapytaniu. Nie napotkasz żadnych problemów, jeśli użyjesz parametrów. Wszystko jest załatwione.

set language us_english 
declare @d datetime = '1929/12/18' 

set language british 
declare @d datetime = '1929/12/18' -- fails 

Aby zmienić domyślny serwer język:

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

Answer 2

Osobiście zawsze wykorzystanie formatu YYYY-MM-DD (lub RRRRMMDD), ponieważ nie jest to specyficzne kulturowo, i dobrze, ja Domyślam się, że to mi się podoba, ponieważ jest "logiczne" (zwłaszcza gdy następuje czas).

[Edit: Ja mówię tylko o tym, co umieścić w moich skryptów SQL, aby zapewnić kompatybilność niezależnie od ustawień serwera, a nie co „wyświetla się” SQL Server]

Answer 3

W prawie wszystkich przypadkach właściwy sposób rozwiązać to po prostu, aby nigdy nie traktować daty jako łańcucha znaków. Jeśli przekazujesz parametr lub używasz (wpisanej) wartości kolumny, konwersja serwera po prostu nie jest czynnikiem. Oprócz uniknięcia problemu i18n, zmniejsza to również powierzchnię ataku wtryskowego. I oszczędza również kilka cykli procesora ;-p

Jeśli używasz EXEC dla dynamicznego SQL, to powinno to być również sparametryzowane przez sp_ExecuteSQL.

Answer 4

Jeśli przechodzą w DATETIME w formacie

dd MMM yyyy 

np

"11 JUL 2009" 

nigdy nie ma niejednoznaczności około miesiąca i daty, a więc nigdy nie powinno mieć problem

Answer 5

I spróbuj użyć kanonicznej postaci ODBC daty, gdzie to możliwe {d 'rrrr-mm-dd'} W ten sposób wiem, jak sql służyć r zinterpretuje to. Działa w TSQL dobrze.

Answer 6

Można ustawić domyślny język dla każdego pojedynczego SQL Server login. Nie pamiętam, ale coś w tym stylu:

sp_defaultlanguage @loginame = 'LoginName', @language = 'Language' 

Answer 7

Dodaj to do swojej strony.Plik konfiguracyjny:

</system.web> 
    <globalization culture="en-US" uiCulture="en-US" /> 
</system.web> 

czy można dodać to oświadczenie na stronie:

<%@ Page uiCulture="en-US" culture="en-US" %> 

Nadzieja ta pomoc.