MySQL Bugs: #23077: ODBC fails when using MS ASCII driver

Bug #23077	ODBC fails when using MS ASCII driver
Submitted:	7 Oct 2006 18:00	Modified:	25 Dec 2006 17:44
Reporter:	Leonardo Ramos	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Migration Toolkit	Severity:	S2 (Serious)
Version:	1.1.4rc	OS:	Windows (XP)
Assigned to:	MySQL Verification Team	CPU Architecture:	Any
Tags:	driver, exception, microsoft, ODBC, reverse engineering, schemata, text

Description:
Microsoft ODBC TEXT driver does not support optional  retrieve schemata names ODBC Function. So it fails when attemting to connect and load the schemata.

The migration tool should detect this exception and move on creating a default schemata and putting all the tables in it.

How to repeat:
create a ODBC source to a TEXT file using the ODBC administration tool at the control panel.

use the ODBC data source as your source database using JDBC generic

use the mysql server as your destination/target

when the tool attemps to connect to odbc it fails because MS did not implement the Schemata ODBC request function, the exeption is so posted in the log.

Suggested fix:
Have the Migration tool detect the exception and generate a default catalog and load all the tables to it

Thank you for a problem report. Please, try to repeat with a newer version, 1.1.4 rc, and inform about the results.

I downloaded the 1.1.4rc version.
The behavior is the same.

Here is the Log:

Connecting to source database and retrieve schemata names.
Initializing JDBC driver ... 
Driver class Generic Jdbc
Opening connection ... 
Connection jdbc:odbc:chicago
The list of schema names could not be retrieved (error: 0).
ReverseEngineeringGeneric.getSchemata :[Microsoft][ODBC Text Driver]Optional feature not implemented
Details: 
sun.jdbc.odbc.JdbcOdbc.createSQLException(Unknown Source)
sun.jdbc.odbc.JdbcOdbc.standardError(Unknown Source)
sun.jdbc.odbc.JdbcOdbc.SQLTables(Unknown Source)
sun.jdbc.odbc.JdbcOdbcDatabaseMetaData.getTables(Unknown Source)
sun.jdbc.odbc.JdbcOdbcDatabaseMetaData.getSchemas(Unknown Source)
com.mysql.grt.modules.ReverseEngineeringGeneric.getSchemata(ReverseEngineeringGeneric.java:191)
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)

Could you explain what exactly are you trying to do? Maybe there is a much simplier solution for your problem.

The Migration Toolkit requires Type 4 JDBC drivers to work as expected. There has been a special handling introduced for the JDBC/ODBC bridge for MS Access but it is out of the scope of the Migration Toolkit to have workarounds for all the limitations found in all of drivers available.

If you are dependent on this functionality inside the Migration Toolkit please feel free to add a new reverse engineering module in Java. We would be eager to add it to the distribution.

I have a 700,000+ records in FIXED LENGTH ASCII file that I want to merge with my current data.  The size of the data is beyond the 65K records limit in MsExel and OpenOffice.

I have made an adhoc script to parse my data into SQL commands batch.

But It would had been nice to have it done using the Migration Tool.

Can you describe the behaviour changes made to the handling introduced for the JDBC/ODBC bridge for MS Access?  I suspect this resolution will solve the issue with the Text dirver as well.

I have a 700,000+ records in FIXED LENGTH UNICODE TEXT file that I want to
merge with my current data.  The amount of data is beyond the 65,000
records limit in MsExcel and OpenOffice.

I have made an adhoc script to parse my data into SQL commands batch.

But It would had been nice to have it done using the Migration Tool.

Thank you for the bug report and feedback. Could you please provide a
small sample file which format are you trying to migrate? Thanks in advance.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".