Home Dashboard Directory Help

Please fix the "String or binary data would be truncated" message to give the column name by DWalker


Status: 

Active


780
3
Sign in
to vote
Type: Suggestion
ID: 339410
Opened: 4/22/2008 10:04:22 AM
Access Restriction: Public
Duplicates: 125347
2
Workaround(s)
view

Description

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.

Details
Sign in to post a comment.
Posted by SVeugelers on 7/7/2014 at 5:52 AM
Come on Microsoft. Such a small change and you would make a lot of developers happy.
Don't see any security risk in this, but would be a great help. Especially since Entity Framework makes the queries even harder to debug:

exec sp_executesql N'INSERT INTO [Table] ([Field1] ...) VALUES (1,...) SELECT @p1 int...', @p1=10,....

So please, please add this to SQL Server. I beg you.
                        
Posted by Lionel Couillard on 5/27/2014 at 10:54 PM
Please fix this error message !

With the number of developers fighting with this issue every day it's a waste of time for everyone !

The global productivity of the developers in the world would increase if the message was mentioning which columns are causing the trouble.
Posted by James DBAnderson on 5/1/2014 at 3:11 AM
Come on MS. This is a real pain when dealing with inserts that have many string columns. Can't be that hard to add this in.
Posted by DWalker on 4/15/2014 at 7:22 AM
As mentioned earlier: Quote from July 2005: "It is a bit too late to change error msgs in the Yukon product cycle; we will improve this error msg in the next release."

Wow, it has been a LONG time since I posted this, and even longer since connect item #125347 which was entered in 2005. Almost 10 years! Usability, usability, usability.

Microsoft, please wake up. Thanks.
Posted by Christopher Enengl on 4/15/2014 at 4:05 AM
So did Microsoft do anything after this 6 Years???

28.04.2008:
"
Hello

Thanks for your feedback. We're tracking your request to improve this error message for a future release of SQL Server.
"
Now we are going to install SQL Server 2014 - but i have no hope at all that this bug is solved "already"...
Posted by Evan Carroll on 12/17/2013 at 2:21 PM
Please don't fix this. I intend to use it as an example of the product's inadequacies for years to come. I've already monkeywrenched my solution.
Posted by Tomislav Bronzin MVP1 on 8/29/2013 at 12:13 AM
Once again I have received this error and went through tedious process of finding in which column it occurs.
Please give this suggestion a priority!
Posted by bbt2d on 7/3/2013 at 12:41 PM
Took me a day to find this:


https://connect.microsoft.com/SQLServer/feedback/details/792499/selective-xml-index-causing-insert-error-string-or-binary-data-would-be-truncated-the-statement-has-been-terminated
Posted by P_m_Durrant on 5/29/2013 at 3:06 AM
knowing Microsoft they will replace it with Object reference not set to an instance of an object error, just to help us developers a bit more
Posted by Robert Heinig II on 5/15/2013 at 12:38 AM
Quote from July 2005: "It is a bit too late to change error msgs in the Yukon product cycle; we will improve this error msg in the next release."

Chuckle. Let's not forget that overall SQL Server is a really great product. It's obvious there are some seriously genius-level brains on the team, let's be happy they are not burdened with usability concerns.
Posted by Mike C1 on 3/15/2013 at 1:30 PM
Out of all the improvements that could be made, this is at the top of the list. Hours & Hours of time trying to track this down every time it happens. Just show the column name, how hard cant that be?
Posted by Sajal Bagchi on 2/1/2013 at 3:05 PM
I completely agree with all. We often get this error while importing a flat file while running an SSIS and since the file has more than 50 columns it is really a tedious work to drill down to correct column. Please give it a priority.
Posted by Jerry Birchler on 1/23/2013 at 2:42 PM
I Agree. My suggestions feel very unreasonable if yours isn't given the most priority. This almost feels like a bug.
Posted by Jamie Thomson on 12/6/2012 at 6:06 AM
This error message crops up often in my SSIS logs where often we're loading data from a 3rd party flat file (i.e. We're not wholly in charge of the data). It would help massively if you could improve this error message.
Posted by k00lb0y on 10/8/2012 at 5:59 AM
Can someone please prioritize this request and ensure this is being addressed. We are living with this error and inability to find the culprit table is a disaster. Always afraid of spending hours on this task during BUSY schedules.

Alternatively, a work around would have been a relief for all these 5 YEARS of time.
Posted by Maximilian Haru Raditya on 8/17/2012 at 2:30 PM
Still no progress???
Posted by xyvyx on 8/17/2012 at 7:37 AM
7 years. It's been at least 7 years that this worthless message has been around yet no fix.

The new Activity Monitor, IntelliSense, the Server Dashboard reports.. how much effort was put into these poorly designed "fluff" features vs. solving real-world problems encountered daily by developers and administrators?
Posted by Chad Dokmanovich on 6/20/2012 at 1:47 PM
The binary workaround does not work well in various situations: 1) setting up test data using SSMS to enter data "directly into the table." or 2) if columns disallows nulls. This work around is still very tedious.

I, too am infuriated by the apparent laziness to provide a betetr error message for such a common development (and sometimes production) error.

This one really needs to be done. bad. real bad.
Posted by JohnMSDEV on 3/15/2012 at 10:14 AM
As a developer programming for the MS platform (and as MSFT stockholder, BTW), this error message, and many other vague error messages are really, really frustrating. These are huge time wasters.

Let me make a business case for MSFT: the more you piss off devs with these difficult to support and debug "features", the less likely they'll stick to making apps for the Microsoft platform. There are already better, competitive alternatives in the open source world.

Face it, the more applications developed by software developers for MS platforms, the better. So make developing for MS, less frustrating, and more robust.

Make MS development products more polished, don't just add more features. Make existing features better, and less frustrating. That should be the priority. So that next time, there won't be apprehension, when considering a new MS project, and perhaps there won't be a flight away from MS development.
Posted by Nicolas BRUSCHINI on 1/5/2012 at 12:05 AM
Please improve this error message. It makes us wasting a lot of time tracking the error when there is a lot of columns !!
Posted by Robert Heinig II on 6/29/2011 at 4:39 AM
@Aaron K: too strong words for connect, the guys reading our effluences here are the good ones, after all.

What they should, however, try to get into the heads of the marketing guys hampering them is that small things like this one do add up immensely where customer satisfaction is concerned, and the customers in this product are not to be taken lightly despite bing 'only' devs - this dev breed often has a lot of weight with both management and users in their companies. And there is a marked trend to a proliferation of such trivialities that make everyday use needlessly frustrating from 2000 to 2005 to 2008 R2, though I'd say this effect is most pronounced in SSRS, slightly less in SSIS, and the core server leaves a positive mood overall (If I took the time to properly document all the flaws I found in the first week after migration I'd be fully bound for well over a month).

@Denis - nope, service crashed with a 0x80040005 Null Pointer Reference Exception, and the proper message deeply hidden in a 64kb stack stace.
Posted by aaron_kempf on 5/15/2011 at 6:18 AM
wow, I think that it is a crime that this was suggested 2 versions ago, and you guys keep postponing. Seriously, can I refer this to the UN for crimes against humanity?
Posted by Denis Valeev on 8/29/2010 at 8:12 AM
(0 row(s) affected)
Posted by tedlong on 8/10/2010 at 9:26 AM
Instead of waiting for the next release, how about just adding this feature to the next service pack.

SELECT 'CommonSense' FROM ms
Posted by AaronBertrand on 8/11/2009 at 4:35 AM
In Connect #125347, Microsoft said, "too late for 2005, we will fix for 2008!" Now, "too late for 2008, we'll fix in vNext!" Please consider fixing this in the next release for real.
Posted by Microsoft on 4/28/2008 at 6:36 PM
Hello

Thanks for your feedback. We're tracking your request to improve this error message for a future release of SQL Server.

-- SQL Server Engine Team
Sign in to post a workaround.
Posted by Trutput on 2/14/2013 at 6:38 AM
The workarround is to vote above so that MS wakes up and realize the message given is ridicoulous.
Posted by Joel Mansford on 2/3/2011 at 2:43 AM
Spend a ridiculous amount of time doing some kind of 'binary' search reducing your insert statement until the error goes away. If there are constraints on the destination table then you have to substitute dummy data which in turn is bad if the system is a production one (afterall these things always happen in production!).