Documentation Home
MySQL 5.7 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 35.6Mb
PDF (A4) - 35.6Mb
PDF (RPM) - 34.7Mb
EPUB - 8.7Mb
HTML Download (TGZ) - 8.5Mb
HTML Download (Zip) - 8.5Mb
HTML Download (RPM) - 7.3Mb
Eclipse Doc Plugin (TGZ) - 9.3Mb
Eclipse Doc Plugin (Zip) - 11.5Mb
Man Pages (TGZ) - 202.2Kb
Man Pages (Zip) - 307.6Kb
Info (Gzip) - 3.3Mb
Info (Zip) - 3.3Mb
Excerpts from this Manual

B.5.2.14 Commands out of sync

If you get Commands out of sync; you can't run this command now in your client code, you are calling client functions in the wrong order.

This can happen, for example, if you are using mysql_use_result() and try to execute a new query before you have called mysql_free_result(). It can also happen if you try to execute two queries that return data without calling mysql_use_result() or mysql_store_result() in between.


User Comments
  Posted by Justin Finkelstein on February 17, 2005
I have just identified and resolved a recurring problem with this error when using PHP in FreeBSD 5.3.

If you're using mysql_pconnect and you call that function repeatedly, and then execute queries on that connection, you will receive this error message. This may be due to the way persistent connections are handled in FreeBSD.

The workaround is to use mysql_connect, which does not generate this error message.
  Posted by Jon Stephens on February 23, 2005
It's best to avoid using mysql_pconnect() in any case, as persistent connections are not supported in PHP 5's mysqli extension (to which all PHP/MySQL development will eventually need to be ported), and really aren't of benefit to Web applications.
  Posted by Peter Sierst Nielsen on March 26, 2005
This error just occured coding C using the "mysqlclient include" having multiple instances of the structure:

struct DB {
MYSQL mysql;
MYSQL_RES *result;
MYSQL_FIELD *field;
MYSQL_ROW row;
unsigned long numRows;
unsigned long numFields;
};

... and THEN forgetting to call init/connect/select_db on all but one.
Just wasted half an hour :| Hope it's going to be of use for the next person.
Regards, Peter Sierst Nielsen
  Posted by Vyacheslav Brover on September 1, 2009
The problem is avoided if prepared statements with cursors are used:

const unsigned long type = (unsigned long) CURSOR_TYPE_READ_ONLY;
mysql_stmt_attr_set (stmt, STMT_ATTR_CURSOR_TYPE, (void*) &type);

Sign Up Login You must be logged in to post a comment.