Do you have a comment or suggestion to improve SQL Server? We’d love to hear it!

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.

1,156 votes
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)

We’ll send you updates on this idea

AdminMicrosoft SQL Server (Product Manager, Microsoft Azure) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

100 comments

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...
An error occurred while saving the comment
  • MJGilchrist commented  ·   ·  Flag as inappropriate

    A clue would be great... Which column maybe? Or better yet the offending Row number and column.

  • Carlos A. Rodriguez commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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!

    Regards.
    Ariel.

  • Andy Steinke commented  ·   ·  Flag as inappropriate

    I am part of the choir - it's 2018, I think we can expect a little more information from errors! Thanks!,

  • Sree commented  ·   ·  Flag as inappropriate

    Even 2017 carry this silly issue What is wrong with Microsoft ???

  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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
    * Column

  • Alexey Voronin commented  ·   ·  Flag as inappropriate

    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.

  • Adrian commented  ·   ·  Flag as inappropriate

    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.

  • Bob Gear commented  ·   ·  Flag as inappropriate

    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?

  • johannwe commented  ·   ·  Flag as inappropriate

    @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.

  • DWalker07 commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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!

Feedback and Knowledge Base