Bug #81944 max_allowed_packet error while migrating nvarchar(max) from MS SQL
Submitted: 21 Jun 2016 8:39 Modified: 14 Oct 2016 21:39
Reporter: Andrii Nikitin Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench: Migration Severity:S3 (Non-critical)
Version:6.3.7 OS:Any
Assigned to: CPU Architecture:Any

[21 Jun 2016 8:39] Andrii Nikitin
Description:
While migrating [nvarchar](max) from MS SQL - Workbench mistakenly complains about max_allowed_packet (please note that max_allowed_packet is set at max value and it is needed to convert only few bytes): 

10:30:53 [DB1][      copytable]: Detected server version=5.6.30-log
10:30:53 [DB1][      copytable]: Detected max_allowed_packet=1073741824
10:30:53 [WRN][      copytable]: 2 characters could not be converted to UTF-8 during copy

How to repeat:
1. Create test table with simple data in MS SQL :
use test;
CREATE TABLE [S]([Value] [nvarchar](max));
insert into [S] values('a');

2. Try to migrate, observe errors (only important messages are provided):

`test`.`S`:Copying 1 columns of 1 rows from table [test].[dbo].[S]
ERROR: `test`.`S`:Found record bigger than max_allowed_packet
ERROR: `test`.`S`:Failed copying 1 rows
FINISHED
Logger set to level 'debug3'. '0111111'
10:30:53 [INF][      copytable]: --table [test]	[dbo].[S]	`test`	`S`	-	-	[Value]
10:30:53 [DB1][      copytable]: Detected server version=5.6.30-log
10:30:53 [DB1][      copytable]: Detected max_allowed_packet=1073741824
10:30:53 [DB2][      copytable]: Columns from source table [test].[dbo].[S] (1):
10:30:53 [DB2][      copytable]: 1 - Value: ntext UNSIGNED (type=SQL_WLONGVARCHAR, len=4294967292, long_data)
10:30:53 [DB2][      copytable]: Columns from target table `test`.`S` (1) [skipped: 0]:
10:30:53 [DB2][      copytable]: 1 - Value: MYSQL_TYPE_BLOB
10:30:53 [WRN][      copytable]: 2 characters could not be converted to UTF-8 during copy

Suggested fix:
From source code it looks that the problem is that max length of column (4294967292) is passed into second argument of MySQLCopyDataTarget::InsertBuffer::append_escaped 

, but actual data length (1) should go instead.

But it is much better to not check max_allowed_packet on client to avoid such problems and only let server reject commands if packet is too big.
[21 Jun 2016 8:49] Andrii Nikitin
Posted by developer:
 
Workaround is to modify column type, e.g.:

alter table S alter column Value nvarchar(4000);
[14 Oct 2016 21:39] Christine Cole
Fixed as of the upcoming MySQL Workbench 6.3.8 release, and here's the
changelog entry:

When migrating a table with a column of type nvarchar(max) from Microsoft
SQL Server, MySQL Workbench found the record to be bigger than the
server's max_allowed_packet value and failed to copy the record to the
server.

Thank you for the bug report.