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/
A clue would be great... Which column maybe? Or better yet the offending Row number and column.
Carlos A. Rodriguez commented
I agree with most comments, to add information to the error message. But especially with the idea of set if I want to truncate.
R McClean commented
Yes please! It would be a great help to have more information in the error message when tracing problems with files.
Lic. Ariel Abaca commented
I would love to have such context information as that given by Oracle. If fact, the error could have an XML representation from the offending row(s) as well, so it can be easily revised.
I believe it is the most anoying of the problems I keep facing with SQL Server, and it is not getting better with the new versions.
Please, Microsoft, help us!
Andy Steinke commented
I am part of the choir - it's 2018, I think we can expect a little more information from errors! Thanks!,
Please, please, please improve this!
it's really annoying!!!
Even 2017 carry this silly issue What is wrong with Microsoft ???
Such big issue especially when dealing with 3rd party data.
A little clue as to the column or key of the row wouldn't be that hard would it?
how about an option to set where it just DOES truncate it and move on...?
Knut Boehnert commented
Preferably the offending column and data is shown on screen with data like e.g. primary key violations. Logging such data in an error log might violate GPDR (another place not intended to store potential PII data).
In order of preference descending to display:
* Column | value | column max length | value max length - all violating rows
* Column | value | column max length | value max length - first occurence
* Column + value
Alexey Voronin commented
Yes, this is really time wasting for many SQL developers, especially when you load 100M rows x 50 columns and have to figure out where exactly this overflow has occurred.
Details of column number and row number that have failed would be great. Or log this in the error logs only if you feel disclosing this information is a security issue.
Marco Perreau commented
It is the most annoying error i kwow!
Agree - it's awful as it is.
Bob Gear commented
I totally agree. The message as it stands is unhelpful almost to the extent of being hostile. Fair point on the security disclosure point - how about activating a more verbose message for diagnosis with a switch?
@MS: Please review this item again!
@PWhiteside: To overcome your valid point, SQL can throw a short message to the user, but log an extended message with more details in the SQL Errorlog. Similar to Login error 18456 since some releases.
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!