The following section details some common errors and their suggested fix or alternative solution. If you are still experiencing problems, use the Connector/ODBC mailing list; see Section 9.1, “Connector/ODBC Community Support”.
Many problems can be resolved by upgrading your Connector/ODBC drivers to the latest available release. On Windows, make sure that you have the latest versions of the Microsoft Data Access Components (MDAC) installed.
I have installed Connector/ODBC on Windows XP x64 Edition or
Windows Server 2003 R2 x64. The installation completed
successfully, but the Connector/ODBC driver does not appear in
ODBC Data Source Administrator.
This is not a bug, but is related to the way Windows x64
editions operate with the ODBC driver. On Windows x64 editions,
the Connector/ODBC driver is installed in the
%SystemRoot%\SysWOW64 folder. However, the
ODBC Data Source Administrator that
is available through the
Control Panel in
Windows x64 Editions is located in the
%SystemRoot%\system32 folder, and only
searches this folder for ODBC drivers.
On Windows x64 editions, use the ODBC administration tool
will correctly locate the installed Connector/ODBC drivers and
enable you to create a Connector/ODBC DSN.
This issue was originally reported as Bug #20301.
When connecting or using the Test button
ODBC Data Source Administrator I get error
10061 (Cannot connect to server)
This error can be raised by a number of different issues, including server problems, network problems, and firewall and port blocking problems. For more information, see Can't connect to [local] MySQL server.
The following error is reported when using transactions:
Transactions are not enabled
This error indicates that you are trying to use
transactions with a
MySQL table that does not support transactions. Transactions are
supported within MySQL when using the
InnoDB database engine, which is
the default storage engine in MySQL 5.5 and higher. In versions
of MySQL before MySQL 5.1, you may also use the
Check the following before continuing:
Verify that your MySQL server supports a transactional
database engine. Use
ENGINES to obtain a list of the available engine
Verify that the tables you are updating use a transactional database engine.
Ensure that you have not enabled the
transactions option in your DSN.
Access reports records as
inserting or updating records in linked tables.
If the inserted or updated records are shown as
#DELETED# in Access, then:
If you are using Access 2000, get and install the newest
(version 2.6 or higher) Microsoft MDAC (
Data Access Components) from
fixes a bug in Access that when you export data to MySQL,
the table and column names aren't specified.
Also, get and apply the Microsoft Jet 4.0 Service Pack 5
(SP5), which can be found at
This fixes some cases where columns are marked as
#DELETED# in Access.
For all versions of Access, enable the Connector/ODBC
Return matching rows option. For Access
2.0, also enable the
Simulate ODBC 1.0
TIMESTAMP in all tables that
you want to be able to update.
Include a primary
key in the table. If not, new or updated rows may
show up as
DOUBLE float fields.
Access fails when comparing with single-precision floats.
The symptom usually is that new or updated rows may show up
#DELETED# or that you cannot find or
If you are using Connector/ODBC to link to a table that has
BIGINT column, the results
are displayed as
#DELETED. The work
around solution is:
Have one more dummy column with
TIMESTAMP as the data
Change BIGINT columns to
INT option in the connection dialog in ODBC
Delete the table link from Access and re-create it.
Old records still display as
but newly added/updated records are displayed properly.
How do I handle Write Conflicts or Row Location errors?
If you see the following errors, select the
Matching Rows option in the DSN configuration dialog,
OPTION=2, as the connection
Write Conflict. Another user has changed your data. Row cannot be located for updating. Some values may have been changed since it was last read.
Exporting data from Access 97 to MySQL reports a
This error is specific to Access 97 and versions of Connector/ODBC earlier than 3.51.02. Update to the latest version of the Connector/ODBC driver to resolve this problem.
Exporting data from Microsoft DTS to MySQL reports a
Using ODBC.NET with Connector/ODBC, while fetching empty string
(0 length), it starts giving the
You can get the patch that addresses this problem from http://support.microsoft.com/default.aspx?scid=kb;EN-US;q319243.
SELECT COUNT(*) FROM
Basic and ASP returns an error.
GetChunk() ADO methods, the
Multiple-step operation generated errors. Check each
status value error is returned.
AppendChunk() methods from ADO do not work
as expected when the cursor location is specified as
adUseServer. On the other hand, you can
overcome this error by using
A simple example can be found from http://www.dwam.net/iishelp/ado/docs/adomth02_4.htm
Another user had modified the record
that you have modified while editing records on a
In most cases, this can be solved by doing one of the following things:
Add a primary key for the table if one doesn't exist.
Add a timestamp column if one doesn't exist.
Only use double-precision float fields. Some programs may fail when they compare single-precision floats.
If these strategies do not help, start by making a log file from the ODBC manager (the log you get when requesting logs from ODBCADMIN) and a Connector/ODBC log to help you figure out why things go wrong. For instructions, see Section 5.8, “Getting an ODBC Trace File”.
When linking an application directly to the Connector/ODBC library under Unix or Linux, the application crashes.
Connector/ODBC under Unix or Linux is not compatible with direct
application linking. To connect to an ODBC source, use a driver
manager, such as
This is a known issue with Connector/ODBC. Ensure that the field
has a default value (rather than
that the default value is nonzero (that is, something other than
When connecting Connector/ODBC 5.x to a MySQL 4.x server, the
1044 Access denied for user 'xxx'@'%' to database
'information_schema' is returned.
Connector/ODBC 5.x is designed to work with MySQL 5.0 or later,
taking advantage of the
database to determine data definition information. Support for
MySQL 4.1 is planned for the final release.
SQLTables, the error
S1T00 is returned, but I cannot find this in
the list of error numbers for Connector/ODBC.
S1T00 error indicates that a general
timeout has occurred within the ODBC system and is not a MySQL
error. Typically it indicates that the connection you are using
is stale, the server is too busy to accept your request or that
the server has gone away.
When linking to tables in Access 2000 and generating links to tables programmatically, rather than through the table designer interface, you may get errors about tables not existing.
There is a known issue with a specific version of the
msjet40.dll that exhibits this issue. The
version affected is 4.0.9025.0. Reverting to an older version
will enable you to create the links. If you have recently
updated your version, check your
directory for the older version of the file and copy it to the
When I try to use batched statements, the execution of the batched statements fails.
Batched statement support was added in 3.51.18. Support for
batched statements is not enabled by default. Enable option
FLAG_MULTI_STATEMENTS, value 67108864, or
select the Allow multiple statements flag
within a GUI configuration.
When connecting to a MySQL server using ADODB and Excel,
occasionally the application fails to communicate with the
server and the error
Got an error reading communication
packets appears in the error log.
This error may be related to Keyboard Logger 1.1 from PanteraSoft.com, which is known to interfere with the network communication between MySQL Connector/ODBC and MySQL.
When using some applications to access a MySQL server using Connector/ODBC and outer joins, an error is reported regarding the Outer Join Escape Sequence.
This is a known issue with MySQL Connector/ODBC which is not
correctly parsing the "Outer Join Escape Sequence", as per the
ODBC Specs. Currently, Connector/ODBC will return a
value > 0 when asked for
SQL_OJ_CAPABILITIES even though no parsing
takes place in the driver to handle the outer join escape
I can correctly store extended characters in the database (Hebrew/CJK) using Connector/ODBC 5.1, but when I retrieve the data, the text is not formatted correctly and I get garbled characters.
When using ASP and UTF8 characters, add the following to your ASP files to ensure that the data returned is correctly encoded:
Response.CodePage = 65001 Response.CharSet = "utf-8"
I have a duplicate MySQL Connector/ODBC entry within my Installed Programs list, but I cannot delete one of them.
This problem can occur when you upgrade an existing Connector/ODBC installation, rather than removing and then installing the updated version.
To fix the problem, use any working uninstallers to remove existing installations; then may have to edit the contents of the registry. Make sure you have a backup of your registry information before attempting any editing of the registry contents.
When submitting queries with parameter binding using
UPDATE, my field values are being
truncated to 255 characters.
Ensure that the
FLAG_BIG_PACKETS option is
set for your connection. This removes the 255 character
limitation on bound parameters.
Is it possible to disable data-at-execution using a flag?
If you do not want to use data-at-execution, remove the corresponding calls. For example:
SQLLEN ylen = SQL_LEN_DATA_AT_EXEC(10); SQLBindCol(hstmt,2,SQL_C_BINARY, buf, 10, &ylen);
SQLBindCol(hstmt,2,SQL_C_BINARY, buf, 10, NULL);
Note that in the call to
&ylen has been replaced by NULL.
For further information, refer to the
When you call
SQLColumns() for a table column
NULLABLE column of the result set is always
This is because MySQL reports the
value for such a column as
NULL. It means, if
you insert a
NULL value into the column, you
will get the next integer value for the table's