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

  • 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!

  • AdminMicrosoft SQL Server (Product Manager, Microsoft Azure) commented  ·   ·  Flag as inappropriate

    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.

1 2 3 5 Next →

Feedback and Knowledge Base