Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

out-of-range value Expand / Collapse
Posted Wednesday, July 10, 2013 4:40 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, June 3, 2016 5:25 AM
Points: 32, Visits: 11,132

I have a system that has been moved from a SQL2008R2 box to a SQL2012 box but there is query it executes (had to run a trace to find it) that throws the old 'The conversion of a varchar data type to a smalldatetime data type resulted in an out-of-range value'. The query is evaluating the UK date '29/05/2013'. I know the best way to fix it would be to amend the query but that would involve the 3rd party to amend the front-end which is not going to happen.

The new server is also running Windows 2012 and I've checked all locales are set to United Kingdom and the dates are set to 'dd\mm\yyyy'. The language the login the front-end uses is also set to 'British English'.

Any thoughts on how to get round this without altering the code. Is SQL2012 more stringent with dates?

Any help greatly appreciated.

Post #1472047
Posted Wednesday, July 10, 2013 6:24 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, October 18, 2016 4:15 PM
Points: 949, Visits: 1,884
Not sure what you mean by "the login front-end". Is this the SQL Server or another server? What happens if you open up a query window in SSMS and run SELECT @@LANGUAGE?

Can you post the query that is throwing the error?

Joie Andrew
"Since 1982"
Post #1472078
Posted Sunday, July 14, 2013 6:48 PM

Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, February 24, 2016 6:28 AM
Points: 3,977, Visits: 6,431
Probably not a great suggestion but if you can't correct it in the fronte end and if this is happening during an INSERT or UPDATE, you could add an INSTEAD OF trigger to the table and fix the value before completing the DML (within that trigger).

My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
Post #1473419
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse