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.

586 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    23 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Anonymous 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!

      • Kevin commented  ·   ·  Flag as inappropriate

        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!

      • PWhiteside commented  ·   ·  Flag as inappropriate

        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.

      • PWhiteside commented  ·   ·  Flag as inappropriate

        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.

      • Tom Verney commented  ·   ·  Flag as inappropriate

        Ahhh, just let us continue to struggle. Did Microsoft ever fix the "error 53 file not found?" Always loved that one.

      • arvind ravish commented  ·   ·  Flag as inappropriate

        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.

      • Brian Petersen commented  ·   ·  Flag as inappropriate

        I have also made a request for this to be implemented, hope it will implemented eventually, better late then never.

      • Manjuke Fernando commented  ·   ·  Flag as inappropriate

        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.

      • Anon commented  ·   ·  Flag as inappropriate

        To clarify: we need column and the VALUE that caused the error. Similar to what's already available for duplicate unique key/index values.

      • Nobody commented  ·   ·  Flag as inappropriate

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

        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!

      ← Previous 1

      Feedback and Knowledge Base