My boss has been very proactive in this area - we already had a weekly "Tea and biscuits" meeting, but he's moved that to Teams and we join in from...

I'd suggest that you look at some of the Stairway articles on this site. All the ones I've read have been extremely  well-written. You can pick topics that cover areas...

As the database is using a case-sensitive collation, I don't see why the 2nd option wouldn't work.

To find out which values are causing the problem, you could use TRY_CAST(YourColumn AS DATE). The values that can't be cast will be null in the new table. Then you...

And how long did it take them to give us a better message than "string or binary truncation"?

Now I really want a picture of Steve in a Smurf shirt!

Good article. The only thing I'd question is having the revision history in the header; over time this can become very verbose and bloat the script considerably. All that information...

That's my guess based on the fact that...

I had a problem a few days ago where using TRY_CAST gave no nulls in the result, but using just CAST caused an error. It turned out that either my...

I was expecting the LEAD solution to need the UNBOUNDED FOLLOWING frame, so I discounted that one.

I have confirmed that the error was caused by a value that was being filtered out later by the joins or the where clause. That's why I never saw nulls...

I tried to script out the values (see below). Selecting from the resulting temporary table works whether I use CAST or TRY_CAST, ie. the value has somehow been fixed by...

• This reply was modified 6 years, 4 months ago by Chris Wooding. Reason: Estimated plan added in case it helps

Phil,

I'll try to reproduce with sample data tomorrow (and post it if I succeed).

Thom,

didn't your large value came through as null when using TRY_CAST? It did when I tried in...

Unfortunately, when I scripted out the inserts, the select worked on the result, ie. just rendering the result into a grid was sufficient to "fix" the underlying error.

Thanks. The highest value I get for LocationOfDP is 7. If there were too many decimal places, I'd have expected the ROUND to fix it.