UTC issue on SQL server - settings? 1

[AndyH1]

I wonder if someone can advice.


I’m running a query which seems to run fine on the live server but gives an overflow error when converting a string in the from ‘2013-03-31 00:00:00’ to a datetime. I found out the reason is its seeing it in the form year-day-month so a month of 31 is obviously wrong.

WHERE W.DateForInvoicing BETWEEN CAST(CAST(@FinancialYear As nvarchar(5)) + '-04-01 00:00:00.000' As datetime)
AND CAST(CAST((@FinancialYear + 1) As nvarchar(5)) + '-03-31 23:59:59.000' As datetime)

I'm using Windows 2003 Server

I can’t however see the difference between the live server and my local version. The regional and language settings are the same in the control panel as on live server, the Server Collation is the same on the SQL Servers Latin1_General_CI_AS, and in Advanced on server properties the Advanced > Default language is English – the same as the live server. The only difference I can see is the SQL server on the live is standard whereas I’m using the developer edition SQL 2005.

I'm a web developer, so actually setting up servers it not my area of expertise, and I'm a bit stumped. I can't find any other regional/country settings

can anyone help
Andy



It doesn’t seem to be a report writer issue as if I run the same code as a query in SQL Management studio I get the same error, so it must be something to do with SQL server



Frankly I’m a bit stumped, do you have any ideas?

Andy

 

[AndyH1]

Have solved this

 

[gmmastros]

Let me guess.... you ended up with something like this...

CAST(CAST([!]Year(@FinancialYear)[/!] As nvarchar([!]4[/!])) + '-04-01 00:00:00.000' As datetime)

-George
Microsoft SQL Server MVP
My Blogs
SQLCop
twitter
"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom

 

[AndyH1]

>Let me guess.... you ended up with something like this... gmmastros

No, thanks for the advise, but that didn't give a problem. Not sure why it was set to 5, I didn't write the original code, but it doesn't cause an issue, if there are extra spaces they get stripped off automatically.

The UTC issue I eventually found out was caused by the user under who the server is logged in being set to British English instead of just English in the security settings of the SQL server. I'd never have guessed that in a million years, but luckily we've got brighter people than me here and someone had encountered the same problem before and so was able to advise me.

 

[gmmastros]

There's a SQLCop check for that.

I wrote SQLCop several years ago. It's a free application that you can use to detect common problems within your database/instance.

If you click the SQLCop link in my signature, you will be able to download it. Once you run it, expand configuration and then click on "Login Language". This will show you all logins with a language that does not match the server's default language.

I only mention this so that you can easily check to see if there are other logins on your server that have an inconsistent language setting.

-George
Microsoft SQL Server MVP
My Blogs
SQLCop
twitter
"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom

 

[AndyH1]

Thanks gmmastros

Tried SQLCop on the server and there don't seem to be any further issues, but its a good tool to have in your inventory.
Andy