I provided the list below for our programmers, who also are dealing with
a switch from 3.23 to 4.1. Perhaps it would be of some help for you.
We've already hit a couple of API-related problems with the new version
of MySQL. To try to make things a little easier, and because I love our
programmers, I've sifted through the change history of MySQL 4.1 to pick
out all the changes specifically related to the C API. Most won't apply
For a complete list of all MySQL changes, hit this link:
And now for the list:
* Added new mysql_get_server_version() C API client function.
* Added mysql_set_server_option() C API client function to allow
multiple statement handling in the server to be enabled or disabled.
* The mysql_next_result() C API function now returns -1 if there are no
more result sets.
* Warning: Incompatible change! Renamed the C API mysql_prepare_result()
function to mysql_get_metadata() as the old name was confusing.
* Added mysql_sqlstate() and mysql_stmt_sqlstate() C API client
functions that return the SQLSTATE error code for the last error.
* Warning: Incompatible change! Renamed prepared statements C API functions:
Old Name New Name
Now all functions that operate with a MYSQL_STMT structure begin with
the prefix mysql_stmt_.
* Warning: Incompatible change! The signature of the
mysql_stmt_prepare() function was changed to int
mysql_stmt_prepare(MYSQL_STMT *stmt, const char *query, unsigned long
length). To create a MYSQL_STMT handle, you should use the
mysql_stmt_init() function, not mysql_stmt_prepare().
* C API enhancement: SERVER_QUERY_NO_INDEX_USED and
SERVER_QUERY_NO_GOOD_INDEX_USED flags are now set in the server_status
field of the MYSQL structure. It is these flags that make the query to
be logged as slow if mysqld was started with --log-slow-queries
* Added support for unsigned integer types to prepared statement API
* Warning: Incompatible change! C API change: mysql_shutdown() now
requires a second argument. This is a source-level incompatibility that
affects how you compile client programs; it does not affect the ability
of compiled clients to communicate with older servers. See section
* Fixed a bug in client-side conversion of string column to MYSQL_TIME
application buffer (prepared statements API). (Bug #4030)
* Fixed a buffer overflow in prepared statements API (libmysqlclient)
when a statement containing thousands of placeholders was executed. (Bug
* The mysql_change_user() C API function now frees all prepared
statements associated with the connection. (Bug #5315)
* Fixed bug in libmysqlclient that fetched column defaults.
* Fixed mysql_stmt_send_long_data() behavior on second execution of
prepared statement and in case when long data had zero length. (Bug #1664)
* You can now call mysql_stmt_attr_set(..., STMT_ATTR_UPDATE_MAX_LENGTH)
to tell the client library to update MYSQL_FIELD->max_length when doing
mysql_stmt_store_result(). (Bug #1647).
* Fixed memory leak in the client library when statement handle was
freed on closed connection (call to mysql_stmt_close after mysql_close).
* Fixed mysql_stmt_affected_rows() call to always return number of rows
affected by given statement. (Bug #2247)
* Fix for a bug that caused client/server communication to be broken
when mysql_set_server_option() or mysql_get_server_option() were
invoked. (Bug #2207)
* The MySQL server did not report any error if a statement (submitted
through mysql_real_query() or mysql_stmt_prepare()) was terminated by
garbage characters. This can happen if you pass a wrong length parameter
to these functions. The result was that the garbage characters were
written into the binary log. (Bug #2703)
* Fixed bug in client library that caused mysql_stmt_fetch and
mysql_stmt_store_result() to hang if they were called without prior call
of mysql_stmt_execute(). Now they give an error instead. (Bug #2248)
* Fixed a bug in mysql_stmt_close(), which hung up when attempting to
close statement after failed mysql_stmt_fetch(). (Bug #4079)
* Fixed potential memory overrun in mysql_real_connect() (which required
a compromised DNS server and certain operating systems). (Bug #4017)
* Fixed a bug that caused libmysql to crash when attempting to fetch a
value of MEDIUMINT column. (Bug #5126)
* Fixed that mysql_options(...,MYSQL_OPT_LOCAL_INFILE,...) failed to
disable LOAD DATA LOCAL INFILE. (Bug #5038)
* Fixed a bug which caused the server to crash when the deprecated
libmysqlclient function mysql_create_db() was called. (Bug #6081)
* Fixed a bug in libmysqlclient with wrong conversion of negative time
values to strings. (Bug #6049).
* Fixed a bug in libmysqlclient with wrong conversion of zero date
values (0000-00-00) to strings. (Bug #6058)
Dave Dyer wrote:
> I have a family of applications which use the C api to access mysql.
> I found by doing a test upgrade to 4.1 that all of these applications
> crash, apparently because the structures passed between my applications
> and libmysql.dll are incompatible. Recompiling the applications fixes
> the problem, but I'm disturbed that these "broken" applications didn't
> fail gracefully, when stale applications presented unusable structures
> to the new libmysql.
> 1) Is there no automatic check for compatibility that I should
> be encountering, and somehow am not?
> 2) In the absense of such a check, what should I build into my "old"
> applications so they will either continue to work or at least fail
> gracefully when the server is permanantly upgraded to 4.1