The most bizarre SQL issue ever

Question

Post reply

The most bizarre SQL issue ever

Viewing 10 posts - 16 through 24 (of 24 total)

You must be logged in to reply to this topic. Login to reply

David Webb-CDS SSCoach Points: 17398 More actions · Answer 1

Another stab..

Indexed views on the table?

And then again, I might be wrong ...
David Webb

SQLWannabe SSCrazy Points: 2842 More actions · Answer 2

No computed columns.

Yes, indexed views.

Everything has worked fine (with our entire load/update process) until this one single value fell into the specified range. The other fields with MONEY data types don't have a value in this range.

David Webb-CDS SSCoach Points: 17398 More actions · Answer 3

Is it possible to drop the view, perform the update, then re-create the view?

And then again, I might be wrong ...
David Webb

WayneS SSC Guru Points: 95460 More actions · Answer 4

SQLWannabe (8/27/2010)
.5. WayneS, love the avatar. LOL!!!

Thanks! You can imagine that I feel like doing that a lot.

Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links:
For better assistance in answering your questions
Performance Problems
Common date/time routines
Understanding and Using APPLY Part 1 & Part 2

WayneS SSC Guru Points: 95460 More actions · Answer 5

Have you figured out anything with this yet?

Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links:
For better assistance in answering your questions
Performance Problems
Common date/time routines
Understanding and Using APPLY Part 1 & Part 2

SQLWannabe SSCrazy Points: 2842 More actions · Answer 6

No, not yet. We've been focusing on other things. However, I will probably get back to it this week. I'm going to try dropping all the indexed views then updating to see if that makes a difference.

WayneS SSC Guru Points: 95460 More actions · Answer 7

SQLWannabe (8/31/2010)
No, not yet. We've been focusing on other things. However, I will probably get back to it this week. I'm going to try dropping all the indexed views then updating to see if that makes a difference.

Actually, you probably don't need to drop them. Check to see if any columns are doing any calculations; if you're just selecting columns then I don't see how that could be the issue. Somewhere, this column is being converted (possibly implicitly), and that is what we need to find.

Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links:
For better assistance in answering your questions
Performance Problems
Common date/time routines
Understanding and Using APPLY Part 1 & Part 2

SQLWannabe SSCrazy Points: 2842 More actions · Answer 8

So, here we are back to this issue again, got the same type of error. Now it's in a different field. Same issue, any value in Table A that needs to be updated in Table B between 999950 and 999999.99 will not update. I get the "arithmetic overflow" error. I'm coding around it, but I don't see why I should have to.

Pam Brisjar SSChampion Points: 12094 More actions · Answer 9

Have you tried running Profiler to capture all SQL activity during the update?

Ellen-477471 SSCrazy Points: 2238 More actions · Answer 10

With all that you have already looked at it seems to point to a data issue.

I suggest that since you only have one record in 7800 that cannot be updated you should look at the source table and replace the data used to do the one record update.

Maintain the values but for each column update with the "existing" value using a direct update statement. This will overwrite any corrupted data that may be causing the failure when trying to update the second table.

This may be a case of the "invisible" character.