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,084 votes
Sign in
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 →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Chris commented  ·   ·  Flag as inappropriate

        So as-of July, 2018, at least 1080 users were frustrated enough with this issue to search & find this topic, sign-up and vote as something that should be fixed. Assuming that they were able to find their way to the new Azure voice feedback site...

        The number of hours wasted by the community diagnosing this is ridiculous compared to both the time required to alleviate the problem and the MS development time for other non-essential features.

      • DWalker07 commented  ·   ·  Flag as inappropriate

        Small point.. The error message actually says "String or binary data would be truncated". The headline has the phrases backwards.

      • Kirk Riz commented  ·   ·  Flag as inappropriate

        Yes please. It would eliminate having to write C# script in SSIS to get the information

      • Robin Wilson commented  ·   ·  Flag as inappropriate

        This would be so helpful and save so much time. Obviously SQL Server knows which column hit the error but the details of the caught error are not passed back to the user leading you to have to keep removing columns until you figure it out.

      • Jane commented  ·   ·  Flag as inappropriate

        Amen! Much better ways to spend our time than chasing this when it happens.

      • [Deleted User] commented  ·   ·  Flag as inappropriate

        Hard to believe this is STILL an issue. It has been irritating sql developers forever and it is clearly obvious that the engine can tell which column(s) are causing the issue. Such a useless generic error message that could be turned into such a helpful thing so easily.

      • Bob commented  ·   ·  Flag as inappropriate

        a more "Oracle Like" error message would be greatly appreciated. I just spent 1/2 day tracking one of these down. What a pain.

      • LeftCoastJames commented  ·   ·  Flag as inappropriate

        This issue has plagued me since my introduction to SQL Server some 20 years ago (SQL Server 6.5). An enhancement is loooong overdue. Just knowing what column overflowed would be sooo much better.

      • Tim commented  ·   ·  Flag as inappropriate

        Fix it, and make the error report useful (please, as always).

      • Anonymous commented  ·   ·  Flag as inappropriate

        This would be so helpful to fix. Being able to pinpoint the row and column causing the issue would make resolving this so much easier. I have lost so much time over the years dealing with this error message

      • Anonymous commented  ·   ·  Flag as inappropriate

        Tell me what table and column it is.

        "there was an error' is the most unuseful error message it is possible to concieve

      • David commented  ·   ·  Flag as inappropriate

        There are some ways to research the issue, but the more columns in the table the more work it takes. Researching this type of issue can be both frustrating and time-consuming. Microsoft--PLEASE fix this issue!

        Here is an example of type of query we run to help pinpoint the offending column:

        SELECT DISTINCT GroupID, LEN(GroupID) FROM db.schm.Membership
        WHERE SourceDataKey = 37859
        and LEN(groupid) > 12
        AND EnrollmentStatusCode IN ('P','N')
        GROUP BY GroupID
        ORDER BY 2 DESC;

        GroupID (No column name)
        ABCDEFG 17
        GFEDCBA 17
        DCEFBAG 17

        After finding the offending column, then one has to find the offending row. Once again, this is a time-consuming process--one that could be avoided if Microsoft were to produce a good diagnostic message that pinpoints the source of the data issue.

      • Kurt commented  ·   ·  Flag as inappropriate

        Not sure what to say that hasn't already been said. How is it this hasn't been fixed already? How many man hours have us users lost trying to find what unnamed column is giving us trouble? Surely more hours that it will take to fix it. Please fix it.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Whenever I have to fix this error in a proc I have to tear the proc down and run it manually. This takes way too long because the error doesn't give the column name that the problem occurred in. It seems like an easy fix to add it.

      ← Previous 1 3 4 5

      Feedback and Knowledge Base