binary or string data would be truncated => error message enhancments
if you have that error (in production), it's not obvious to see which column or row this error comes from, and how to locate it exactly.
it's even more complicated if it's coming from a trigger, for example, and not the original insert/update.
I have seen that oracle meanwhile gives clear information which column the error is raising, which actual data length was passed, and the column's max size.
Michael Irwin commented
The system knows enough to fail the import so at least include the column number that fails!!
I am the person who opened this issue in Connect 2008. Ten years! It looks like some of the comment history did not get copied over, but oh well.
A few years ago, someone seemed to be actively looking at improving this. And again, in March 2018, someone said they were actively looking at improving this.
I didn't realize that this item had SO many votes. Interesting. It would be a huge usability improvement.
I know it is not bright new or shiny, but a practical error message fix. I first hit this issue well over a decade ago and it is still not fixed!
This would be an excellent error to update with further details! To PWhiteside's point below, maybe if it shared the table name, column name and max size a DBA or developer could figure out the offending row/value. On the other hand, a good application won't show these errors to end users anyway!
Regarding exposing the errant column value, consider how this might increase the surface area for malicious attacks:
"binary or string data would be truncated ... value '\\SomeSecretServerName\UploadedDocuments\UploadedDocumentWithVeryLongName.ext' is too large for schema.table.column ...'
Now you've exposed the name of one of your servers. Many potential scenarios here where data other than that entered by an end user could be accidentally exposed.
Amen and as stated earlier please give us the errant value too
Thank you all for the feedback, we are actively looking at addressing this.
Steve Malcolm commented
I cannot imagine how many hours this one has cost me. Please implement.
Over decades working with SQL, this is probably the single-largest time waster in resolving support issues. Seriously. Enhancing this error message is 20+ years overdue.
Include the schema.table.column name, the size being violated and the size causing the violation - but NOT the column value - there may be application generated values involved (eg server filesystem path names) that should never be broadcast out to a client in the event of an error.
Nick Baras commented
Please add this
Tom Verney commented
Ahhh, just let us continue to struggle. Did Microsoft ever fix the "error 53 file not found?" Always loved that one.
Brett Estes commented
Please have mercy upon us and add this enhancement.
arvind ravish commented
This sucks without the actual column failing and extremely hard to trace if the application is failing because of this without expertise in database administration
Event the client needs to send back this information for logging and stack traces.
please, please fix this. Painful to say the least.
Brian Petersen commented
I have also made a request for this to be implemented, hope it will implemented eventually, better late then never.
Manjuke Fernando commented
Yes. This is indeed a pain when you have to find the column in a big table. Please include the column details in the error.
To clarify: we need column and the VALUE that caused the error. Similar to what's already available for duplicate unique key/index values.
Look, People, this message must stay as it is by now, for compatibility. Or it is an easter egg. Or tinysquishy doen't dare go against expectations. No, I don't think we'll see an improvement this decade.
Daniel Smith commented
Both this issue, and the fact that we have to start voting again from 0 (when we already had over 1500 votes on Connect) are very irritating!