Bug #68285 | Getting Errors while Migrating data from MS SQL to MY SQL | ||
---|---|---|---|
Submitted: | 6 Feb 2013 5:20 | Modified: | 25 Mar 2013 18:22 |
Reporter: | Hakoo Desai | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Workbench: Migration | Severity: | S1 (Critical) |
Version: | MySQL 5.5 | OS: | Windows |
Assigned to: | CPU Architecture: | Any | |
Tags: | database-migration, MySQL, sql-server |
[6 Feb 2013 5:20]
Hakoo Desai
[25 Mar 2013 18:21]
Sergio Andres De La Cruz Rodriguez
1. The changes in the encoding should not affect the encoded strings. Usually your application logic is the one that handles the decoding of the data. There's an issue, however, when putting international chars in non national fields using some encoding different than UTF-8 (see bug 66516). The fix for that should be out in the next Workbench release. 2. BIT vs TINYINT(1). There's no agreement on what should the preferred target type be (see bug 60701 for an explanation). 3. "should be float, was MYSQL_TYPE_DOUBLE": already reported (bug 67234) This bug is marked as duplicate of bug 67234.
[25 Mar 2013 18:25]
Sergio Andres De La Cruz Rodriguez
Thank you very much for your bug report
[7 Jun 2013 3:55]
Kevin Scott
The original bug description describes an issue with migration of DATETIME fields Specifically: ***08:43 [WRN][ copytable]: Invalid timestamp literal detected: ''*** Actually I don't have any timestamp field, all are DateTime, and set null By default. I am having this issue with v5.2.47. This bug is marked as a duplicate but the referenced issue does not address this DATETIME problem.
[7 Jun 2013 12:49]
Sergio Andres De La Cruz Rodriguez
Hakoo, Kevin: Can you provide a sample SQL Server CREATE TABLE and INSERT INTO statements that can be used to reproduce this DATETIME issue?