Showing posts with label bugs. Show all posts
Showing posts with label bugs. Show all posts
Tuesday, January 10, 2017
T-SQL Tuesday #86: String or binary data would be truncated
This month's T-SQL Tuesday is hosted by Brent Ozar, he proposed the following
Find the most interesting bug or enhancement request (and it can be your own), and write a blog post about it (including a link to the Connect item so that folks who agree with you can upvote the item)
Msg 8152, Level 16, State 6, Procedure <ProcName>, Line 61
String or binary data would be truncated.
This is like not having the black box after a plane crashed, you know the plane crashed, but you don't know why exactly.
Dealing with this issue on a semi-regular basis, I even have written my own T-SQL helper to quickly see where the issue is
Something like this only helps you if you have the data readily available, what if it is from an application? In that case you need profiler or extended events to capture the statement
It is also crazy that this connect item is almost 9 years old, it was opened in April 2008
We do have someone from Microsoft commenting on this issue last August
This connect item has 1328 upvotes as of today, it also has 5 downvotes (who are these people..probably working on the SQL Server team :-) )
Find the most interesting bug or enhancement request (and it can be your own), and write a blog post about it (including a link to the Connect item so that folks who agree with you can upvote the item)
This one was pretty easy for me, it is the following connect item Please fix the "String or binary data would be truncated" message to give the column name
This error drives me crazy as well, it should be fairly easy to tell me if nothing else what damn column barfed on the data inserted, but no.. all you get is something like
This is like not having the black box after a plane crashed, you know the plane crashed, but you don't know why exactly.
Dealing with this issue on a semi-regular basis, I even have written my own T-SQL helper to quickly see where the issue is
declare @ImportTable varchar(100) declare @DestinationTable varchar(100) select @ImportTable = 'temp' select @DestinationTable = 'TestTrunc' declare @ImportTableCompare varchar(100) declare @DestinationTableCompare varchar(100) select @ImportTableCompare = 'MaxLengths' select @DestinationTableCompare = 'TempTrunc' declare @sql varchar(8000) select @sql = '' select @sql = 'select 0 as _col0 ,' select @sql += 'max(len( ' + column_name+ ')) AS ' + column_name + ',' from information_schema.columns where table_name = @ImportTable and data_type in('varchar','char','nvarchar','nchar') select @sql = left(@sql,len(@sql) -1) select @sql +=' into ' + @ImportTableCompare + ' from ' + @ImportTable --select @sql -debugging so simple, a caveman can do it exec (@sql) select @sql = '' select @sql = 'select 0 as _col0, ' select @sql += '' + convert(varchar(20),character_maximum_length)
+ ' AS ' + column_name + ',' from information_schema.columns where table_name = @DestinationTable and data_type in('varchar','char','nvarchar','nchar') select @sql = left(@sql,len(@sql) -1) select @sql +=' into ' + @DestinationTableCompare --select @sql -debugging so simple, a caveman can do it exec (@sql) select @sql = '' select @sql = 'select ' select @sql += '' + 'case when t.' + column_name + ' > tt.' + column_name + ' then ''truncation'' else ''no truncation'' end as '+ column_name + ',' from information_schema.columns where table_name = @ImportTableCompare and column_name <> '_col0' select @sql = left(@sql,len(@sql) -1) select @sql +=' from ' + @ImportTableCompare + ' t join ' + @DestinationTableCompare + ' tt on t._col0 = tt._col0 ' --select @sql -debugging so simple, a caveman can do it exec (@sql) exec ('drop table ' + @ImportTableCompare+ ',' + @DestinationTableCompare )
Something like this only helps you if you have the data readily available, what if it is from an application? In that case you need profiler or extended events to capture the statement
It is also crazy that this connect item is almost 9 years old, it was opened in April 2008
We do have someone from Microsoft commenting on this issue last August
Posted by David [MSFT] on 8/5/2016 at 1:39 PM
Latest update - the developer working on it understands the challenges involved in creating a full fix. It may be tricky to plumb the information about columns needed to generate a full error message down to the actual conversion function in such a way that won't impact insert or update performance. We may implement something cheap in the short term such as logging the type and length of the data being truncated. It's still too early to know when such a fix would reach a publicly visible release.
So there you have it that is my contribution to T-SQL Tuesday # 86, keep track of Brent's blog here https://www.brentozar.com/blog/ there will be a recap posted on Tuesday, January 2017
Thursday, November 03, 2016
Want to know if your connect item is fixed? There is a twitter account for that
Did you know there is a twitter account that will tweet when a connect item is closed or resolved as fixed? I first heard about this account at the Pass Summit last week, then I promptly forgot about it. This morning I was listening to SQL Server Radio show 59, in this show the hosts Matan Yungman and Guy Glantser were talking about this twitter account. I decided to check out this account and follow this account
Here are some examples of tweets from the Closed as Fixed twitter account
Publishing dacpac to SQL Database fails when database uses memory optimized features & target database is in database pool
Publishing dacpac to SQL Database fails when database uses memory optimized features & target database is in data... https://t.co/BLuccCmk1C— Closed as Fixed (@closedasfixed) November 1, 2016
In the actual execution plan, display Reads, writes, CPU ,duration top 3 waitypes/wait duration info for each query
In the actual execution plan, display Reads, writes, CPU ,duration top 3 waitypes/wait duration info for each que... https://t.co/3ZiGRa2RY4— Closed as Fixed (@closedasfixed) October 29, 2016
SSMS silently reconnects to the default database when connection is lost
SSMS silently reconnects to the default database when connection is lost - Erland Sommarskog https://t.co/g9rnYVPl2h— Closed as Fixed (@closedasfixed) October 28, 2016
Subscribe to:
Posts (Atom)