views:

796

answers:

6

Hi Guys

On my test DB, the dates are displayed in a DD/MM/YYYY format. By displayed I mean when you right click, open table in Management Studio, the returned data are displayed in a DD/MM/YYYY format.

Funny thing is, when I write T-SQL to retrieve records, I have to input a MM/DD/YYYY format to get back the right data. Is there anyway I can align this to a DD/MM/YYYY format?

+3  A: 
Mehrdad Afshari
This is a great but I am looking for a permanent solution rather than a session solution.
Nai
Sweet. FYI the correct table name is sys.syslanguages. Also, I just found out you can changed the default language on a user level as well by going to Security -> User Login -> Properties -> Language. Thanks for that Mehrdad
Nai
Nai: syslanguages alone will work if you are in master database. Adding `sys.` to that line made the scrollbars appear so I shortened it ;)
Mehrdad Afshari
Oh ok I didnt know that :P
Nai
+2  A: 

Personally, I always use YYYY-MM-DD format (or YYYYMMDD) since it's not culture-specific, and, well, I guess it appeals to me because it's "logical" (especially when followed by a time).

[Edit: I'm just talking about what I put in my SQL scripts to ensure compatibility regardless of the server settings, not what SQL Server "displays"]

Gary McGill
How does one go about changing the T-SQL Datime query defaults to this?
Nai
Sorry, should have been more specific - answer updated.
Gary McGill
+1  A: 

In almost all cases, the correct way to solve this is simply to never treat the date as a string. If you pass in a parameter, or use the (typed) column value, then the server's text conversion simply isn't a factor. In addition to avoiding the i18n issue, this also reduces your injection attack surface. And it saves a few CPU cycles, too ;-p

If you are using EXEC for dynamic SQL, then this should likewise be parameterised via sp_ExecuteSQL.

Marc Gravell
The dates are acutally stored as DATETIME formats. Sorry if I wasn't clear.
Nai
I assumed that; my point is that it shouldn't *matter* how the server wants to handle them as text if you simply never (in your system) *treat* them as text.
Marc Gravell
Oh right I get what you mean. I normally pass them in as variables but good advice nonetheless. Thanks for that!
Nai
+1  A: 

If you pass in DATETIME in the format

dd MMM yyyy

for example

"11 JUL 2009"

there is never any ambiguity around month and date and therefore you should never have a problem

Russ Cam
A: 

I try to use the ODBC canonical form of a date wherever possible {d 'yyyy-mm-dd'} This way I know how sql server will interpret it. It works in TSQL just fine.

Will Rickards
+1  A: 

You can set the default language for each indvidual SQL Server login. Can't quite remember, but something like this:

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