Why isn't “String or Binary data would be truncated” a more descriptive error?

Question

To start: I understand what this error means - I\'m not attempting to resolve an instance of it.

This error is notoriously difficult to troubleshoot

Answer 1

Microsoft is lazy?

You don't have to try each row insert separately, by the way. Just query for max(len(field)) for each text column, starting with the ones you suspect might be the culprit.

Answer 2

After not finding an acceptable answer anywhere I came up with the following:

1. Get the query that is causing the problems (you can also use SQL Profiler if you dont have the source)
2. Remove all WHERE clauses and other unimportant parts until you are basically just left with the SELECT and FROM parts
3. Add WHERE 0 = 1 (this will select only table structure)
4. Add INTO [MyTempTable] just before the FROM clause

You should end up with something like

SELECT
 Col1, Col2, ..., [ColN]
INTO [MyTempTable]
FROM
  [Tables etc.]
WHERE 0 = 1

This will create a table called MyTempTable in your DB that you can compare to your target table structure to see where they differ i.e. you can compare the columns on both tables.

EDIT: You can compare the data types and column sizes of each column on the original table and MyTempTable to see where they differ.All column names in your new table will be the same as the old, and the data types and sizes will be the same EXCEPT where the offending column is. In other words, with this query, SQL will automatically create columns that are large enough to handle the largest possible entry from the source table

Answer 3

I had this error too, but I found what was causing:

<option>description</option>  <-- this is not error but is wrong
<option value="option1">option1</option>
<option value="option2">option2</option>
<option value="option3">option3</option> 

My MVC application recivies "value" as empty strig ant that causes exception

Answer 4

Descriptive error messages in software systems are as good as non-existant.

That holds not only for DBMS's but for as good as any kind of software one can imagine.

I think the underlying reason is that "good descriptive error messages" take too much time to implement. It is not part of the average software developer's culture to spend much time thinking about "which information would the user want to see if this particular kind of exception occurs" ? The programmers who have to write down the code for giving "good descriptive error messages" only see the cost (their time), not the benefit.

One of the most recent error messages I got from a software system is "Something wrong has happened. Please try again later.". No kidding.

Answer 5

Short Answer: That's just how it is.

Longer Answer: I could see value in showing the row number and column, maybe but it probably wouldn't make sense to show the actual information being truncated. With the VARCHAR(10) scenario, it's probably not a big deal, but excessively large size data would be a whole lot useful. But hopefully no one here is inserting anything more than a VARCHAR(MAX) can hold ;)

Answer 6

It turns out there's an open "feature request" for this on MS Connect - I'd encourage you to vote for it if you'd like the functionality changed.

https://connect.microsoft.com/SQLServer/feedback/details/339410/

ADDED:

It actually looks like there's another request for this same feature (though poorly named) that's been outstanding since Yukon's development in 2005 that I'd encourage people to vote for as well:

https://connect.microsoft.com/SQLServer/feedback/details/125347/

Update 2016

It seems Microsoft has tried to delete evidence of this bug's true age. Fair enough. Find the old site archived here.