Workbench Migration Wizard: Problems with SQL Server as Source

[Chris Smola]

My goal is to use Workbench 6.0.8.11354 build 833 to successfully migrate an SQL Server 2000 db (source) to a local MySQL 5.6.13 db (target) on OS X 10.8.2. I am using the FreeTDS driver (v0.91) to connect to the source. Using the migration wizard, I am able to successfully connect to the source db and implement the source schema locally. I chose the option to translate [database].[schema].[table] into `database`.`table`. Everything appears to work as expected up until the actual data transfer. For the snippets below, I have omitted irrelevant columns to conserve space.

The Workbench-generated schema:
-----
CREATE TABLE IF NOT EXISTS `database`.`table` (
`product_id` VARCHAR(40) NOT NULL,
`description` VARCHAR(254) NULL,
`long_description` LONGTEXT NULL,
PRIMARY KEY (`product_id`));
-----


In the source db, every row in the table has a null value for both the `description` and `long_description` fields. When the time comes to transfer the data, the following error occurs:
-----
...
12:32 [DB1][ copytable]: Detected server version=5.6.13
12:32 [DB1][ copytable]: Detected max_allowed_packet=4194304
12:32 [DB2][ copytable]: Columns from source table [database].[schema].[table] (3):
12:32 [DB2][ copytable]: 1 - product_id: nvarchar (type=SQL_WVARCHAR, len=160)
12:32 [DB2][ copytable]: 2 - description: nvarchar (type=SQL_WVARCHAR, len=1016)
12:32 [DB2][ copytable]: 3 - long_description: ntext (type=SQL_WLONGVARCHAR, len=4294967292, long_data)
`database`.`table`:Copying 11 columns of 252050 rows from table [database].[schema].[table]
12:32 [DB2][ copytable]: Columns from target table `database`.`table` (3):
12:32 [DB2][ copytable]: 1 - product_id: MYSQL_TYPE_STRING
12:32 [DB2][ copytable]: 2 - description: MYSQL_TYPE_STRING
12:32 [DB2][ copytable]: 3 - long_description: MYSQL_TYPE_BLOB
ERROR: `database`.`table`:Got SQL_NO_TOTAL for string size during copy of column 2
...
-----


After doing a bit of research, I have come up with a theory. The SQL_NO_TOTAL [constant?] is returned by the SQLGetData() function. According the MSDN documentation, this constant is returned only when the function cannot determine the length of the string which is contained in a field. My best guess is that Workbench is running that function in one way or the other as it migrates data but does not account for null values in fields with string-like types. As a result, NO data is transferred and the migration completes with:
-----
Copy helper has finished

Data copy results:
- `database`.`table` has FAILED (0 of 252050 rows copied)
0 tables of 1 were fully copied
-----


So my question is this: Is my issue a bug discovery or is there some other explanation/solution?



Edited 3 time(s). Last edit at 01/20/2014 10:52PM by Chris Smola.