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.
This feature is shipped in SQL Server 2017 CU12, SQL Server 2019 CTP and upcoming SQL Server 2016 CP2 CU. Read more at https://blogs.msdn.microsoft.com/sql_server_team/string-or-binary-data-would-be-truncated-replacing-the-infamous-error-8152/
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!
Talley Ouro commented
Add this feature.
Jon of All Trades commented
This is the top-voted SQL issue on Microsoft Connect (https://connect.microsoft.com/SQLServer/Feedback), with 1,609 up-votes over almost ten years.
After all these years, the message
Msg 8152, Level 16, State 6, Procedure <ProcName>, Line 61
String or binary data would be truncated.
is a little outdated. PLEASE tell us the name of the column that is too short to hold the data. We can figure it out, eventually, but it is often tedious. The system knows the answer, so it should tell us.
This would greatly simplify developers' lives. While you're at it, why not say whether it's STRING data or BINARY data?
This reminds me of a hypothetical error message that says "There's an error somewhere, but we're not going to tell you where it is. You have to find it yourself."
All information that the system has, which can be given to the programmer, should be given.