MySQL Bugs: #27050: The schema could not be reverse engineered (error: 0).

Bug #27050	The schema could not be reverse engineered (error: 0).
Submitted:	12 Mar 2007 15:10	Modified:	30 Apr 2007 8:51
Reporter:	Christoph Moebus	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Migration Toolkit	Severity:	S1 (Critical)
Version:	1.1.10	OS:	Any (Server 2003 Enterprise Edition)
Assigned to:		CPU Architecture:	Any

Description:
The following error is reported, when trying to reverse engineer the source database (MSAccess):
The schema could not be reverse engineered (error: 0).
ReverseEngineeringAccess.reverseEngineer :Illegal group reference
Details: 
java.util.regex.Matcher.appendReplacement(Unknown Source)
java.util.regex.Matcher.replaceAll(Unknown Source)
java.lang.String.replaceAll(Unknown Source)
com.mysql.grt.modules.ReverseEngineeringGeneric.establishConnection(ReverseEngineeringGeneric.java:77)
com.mysql.grt.modules.ReverseEngineeringAccess.reverseEngineer(ReverseEngineeringAccess.java:92)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
com.mysql.grt.Grt.callModuleFunction(Unknown Source)

How to repeat:
How to repeat:
Selecting the following option during the migration:
1.:-Direct migration
2.:- Source Database: MS Access, driver=access, database with password
3.:- Target Database: MySQL Server, Connection: hostname, port and correct
password
4.:- Connecting to servers: works
5.:- Source Schemata Selection, select the standard "test" schemata to be migrated; by the way - only this standard "test" schemata is listed, a schemata that is created with "MySQL Administrator" is not listed!
6.: - the above error occurs

I am using MySQL-Server 5.0.37-community-nt

Thank you for the bug report. Could you please provide the Access mdb file
to test on our side?. Thanks in advance.

I have uploaded the Access Database via FTP, because it was bigger than 500kb

I have uploaded the Access Database via FTP, because it was bigger than 500kb

Thank you for the feedback, which is the name of the file you have
uploaded?. Thanks in advance.

The uploaded filename is:
bug-data-27050.zip

Thank you for the feedback. You need to provide me the database password.
Thanks in advance.

Thank you for the feedback.

The schema could not be reverse engineered (error: 0).
ReverseEngineeringAccess.reverseEngineer :Illegal group reference
Details: 
java.util.regex.Matcher.appendReplacement(Unknown Source)
java.util.regex.Matcher.replaceAll(Unknown Source)
java.lang.String.replaceAll(Unknown Source)
com.mysql.grt.modules.ReverseEngineeringGeneric.establishConnection(ReverseEngineeringGeneric.java:77)
com.mysql.grt.modules.ReverseEngineeringAccess.reverseEngineer(ReverseEngineeringAccess.java:92)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
com.mysql.grt.Grt.callModuleFunction(Unknown Source)

I'm having exactly the same issue as Christoph in a different environment.
Importing from an Oracle Database on RH AES 4 to a MySQL-Max Db on a different AES4 server.

The migration toolkit fails at the reverse engineering phase with

Call Oracle stored procedure ANALYZE_SCHEMA for DBSNMP.
CALL DBMS_UTILITY.ANALYZE_SCHEMA(?,  'ESTIMATE', 50, 0, 'FOR TABLE')
The schema could not be reverse engineered (error: 0).
ReverseEngineeringOracle.reverseEngineer :Protocol violation
Details: 
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:125)
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:162)
oracle.jdbc.driver.DatabaseError.check_error(DatabaseError.java:885)
oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:640)
oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:181)
oracle.jdbc.driver.T4CPreparedStatement.execute_for_rows(T4CPreparedStatement.java:543)
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1028)
oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:2888)
oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:2979)
com.mysql.grt.modules.ReverseEngineeringOracle.reverseEngineer(ReverseEngineeringOracle.java:121)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
com.mysql.grt.Grt.callModuleFunction(Unknown Source)

I'm unsure as to whether I should report this as a seperate bug as it is the same error on a different OS and DB

I have exchanged the string.replace() routine to correctly handle special characters like $. Still I was not able to access the database because of the global database password. There seems to be no way of specifying that password with a ODBC connection.

After I removed the global database password the migration process would work. I found another issue with some index names being longer than 32 chars. These are now also truncated to 32 chars to make the migration progress go through smoothly.

If you know how to provide the global database password in an ODBC connection please provide feedback for that. You can specify the ODBC connection string explicitly by pressing [Advanced ...] on the connection page. 

As a workaround, please disable the global password for the migration process.