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.

Cheers,

--V

-------------
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 to us.


For a complete list of all MySQL changes, hit this link:
http://dev.mysql.com/doc/mysql/en/News.html

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
mysql_bind_param() mysql_stmt_bind_param()
mysql_bind_result() mysql_stmt_bind_result()
mysql_prepare() mysql_stmt_prepare()
mysql_execute() mysql_stmt_execute()
mysql_fetch() mysql_stmt_fetch()
mysql_fetch_column() mysql_stmt_fetch_column()
mysql_param_count() mysql_stmt_param_count()
mysql_param_result() mysql_stmt_param_metadata()
mysql_get_metadata() mysql_stmt_result_metadata()
mysql_send_long_data() mysql_stmt_send_long_data()
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 --log-queries-not-using-indexes.
* Added support for unsigned integer types to prepared statement API (Bug #3035).
* 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 21.2.3.51 mysql_shutdown().
* 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 #5194)
* 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). (Bug #3073)
* 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




-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]



Reply via email to