I work in a University Library and we are moving to a new library system. The move does not include historical data and I'm hoping to migrate our current Sybase db to MySql database so we can refer to it for future use. (essential for some financial information)
I'm having problems with the Mysql Workbench Migration from Sybase.
I'm using Workbench 6.2 on Windows 7. ODBC to connect to Sybase ASE 15. Mysql 5.5.1
All seems well through the wizard. Connections seem ok. the database structure is created successfully in MySQL. The problem comes at the actual migration of data, nearly all tables fail (but not all).
The tables fail due to a type mismatch.
eg from the logs
ERROR: `prod_talis`.`ITEM_DESCRIPTION_TYPE`:Type mismatch fetching field 2 (should be char, was MYSQL_TYPE_STRING)
ERROR: `prod_talis`.`ITEM_DESCRIPTION_TYPE`:Failed copying 666 rows
`prod_talis`.`ITEM_QUERY`:Copying 19 columns of 27728 rows from table [prod_talis].[dbo].[ITEM_QUERY]
ERROR: `prod_talis`.`ITEM_QUERY`:Type mismatch fetching field 1 (should be long, was MYSQL_TYPE_STRING)
`prod_talis`.`ITEM_CHECK_IN`:Copying 17 columns of 147524 rows from table [prod_talis].[dbo].[ITEM_CHECK_IN]
ERROR: `prod_talis`.`ITEM_CHECK_IN`:Type mismatch fetching field 1 (should be long, was MYSQL_TYPE_STRING)
ERROR: `prod_talis`.`ITEM_QUERY`:Failed copying 27728 rows
Looking at one field as an example: ITEM_DESCRIPTION_TYPE.SUB_TYPE (field 2 in that table)
The actual Sybase type is tinyint.
At the Source Migration stage we get the following warning
WARNING: Sybase reverseEngineerTableColumns: Column datatype "TYPE" for column "SUB_TYPE" in table "dbo.ITEM_DESCRIPTION_TYPE" reverse engineered as VARCHAR(255)
Oddly the 'Source Type' for SUB_TYPE is listed as VARCHAR(255) Manual editing screen.
And finally at the migration stage it fails the whole table with
ERROR: `prod_talis`.`ITEM_DESCRIPTION_TYPE`:Type mismatch fetching field 2 (should be char, was MYSQL_TYPE_STRING)
Any idea what we can do here?
It looks like the issue is identifying field data types correct in Sybase. It's also odd that the process refers to the same SOURCE field as "TYPE, VARCHAR and char".
With hundreds of tables and thousands of fields this will be very tricky to resolve manually.
Any pointers appreciated?!
Kind Regards
Chris Keene
I'm having problems with the Mysql Workbench Migration from Sybase.
I'm using Workbench 6.2 on Windows 7. ODBC to connect to Sybase ASE 15. Mysql 5.5.1
All seems well through the wizard. Connections seem ok. the database structure is created successfully in MySQL. The problem comes at the actual migration of data, nearly all tables fail (but not all).
The tables fail due to a type mismatch.
eg from the logs
ERROR: `prod_talis`.`ITEM_DESCRIPTION_TYPE`:Type mismatch fetching field 2 (should be char, was MYSQL_TYPE_STRING)
ERROR: `prod_talis`.`ITEM_DESCRIPTION_TYPE`:Failed copying 666 rows
`prod_talis`.`ITEM_QUERY`:Copying 19 columns of 27728 rows from table [prod_talis].[dbo].[ITEM_QUERY]
ERROR: `prod_talis`.`ITEM_QUERY`:Type mismatch fetching field 1 (should be long, was MYSQL_TYPE_STRING)
`prod_talis`.`ITEM_CHECK_IN`:Copying 17 columns of 147524 rows from table [prod_talis].[dbo].[ITEM_CHECK_IN]
ERROR: `prod_talis`.`ITEM_CHECK_IN`:Type mismatch fetching field 1 (should be long, was MYSQL_TYPE_STRING)
ERROR: `prod_talis`.`ITEM_QUERY`:Failed copying 27728 rows
Looking at one field as an example: ITEM_DESCRIPTION_TYPE.SUB_TYPE (field 2 in that table)
The actual Sybase type is tinyint.
At the Source Migration stage we get the following warning
WARNING: Sybase reverseEngineerTableColumns: Column datatype "TYPE" for column "SUB_TYPE" in table "dbo.ITEM_DESCRIPTION_TYPE" reverse engineered as VARCHAR(255)
Oddly the 'Source Type' for SUB_TYPE is listed as VARCHAR(255) Manual editing screen.
And finally at the migration stage it fails the whole table with
ERROR: `prod_talis`.`ITEM_DESCRIPTION_TYPE`:Type mismatch fetching field 2 (should be char, was MYSQL_TYPE_STRING)
Any idea what we can do here?
It looks like the issue is identifying field data types correct in Sybase. It's also odd that the process refers to the same SOURCE field as "TYPE, VARCHAR and char".
With hundreds of tables and thousands of fields this will be very tricky to resolve manually.
Any pointers appreciated?!
Kind Regards
Chris Keene