- 20.9 MySQL C API
- 20.9.1 C API Data Types
- 20.9.2 C API Function Overview
- 20.9.3 C API Function Descriptions
- 20.9.4 C API Prepared Statements
- 20.9.5 C API Prepared Statement Data types
- 20.9.6 C API Prepared Statement Function Overview
- 20.9.7 C API Prepared Statement Function Descriptions
- 20.9.8 C API Threaded Function Descriptions
- 20.9.9 C API Embedded Server Function Descriptions
- 20.9.10 Common Questions and Problems When Using the C API
- 20.9.11 Controlling Automatic Reconnection Behavior
- 20.9.12 C API Support for Multiple Statement Execution
- 20.9.13 C API Prepared Statement Problems
- 20.9.14 C API Prepared Statement Handling of Date and Time Values
- 20.9.15 C API Support for Prepared CALL Statements
- 20.9.16 Building Client Programs
Here follows a list of the currently known problems with prepared statements:
TIME,TIMESTAMP, andDATETIMEdo not support parts of seconds (for example, fromDATE_FORMAT()).When converting an integer to string,
ZEROFILLis honored with prepared statements in some cases where the MySQL server doesn't print the leading zeros. (For example, withMIN().number-with-zerofill)When converting a floating-point number to a string in the client, the rightmost digits of the converted value may differ slightly from those of the original value.
Prepared statements use the query cache under the conditions described in Section 7.5.5.1, “How the Query Cache Operates”.
Prepared statements do not support multi-statements (that is, multiple statements within a single string separated by “
;” characters).In MySQL 5.4, prepared
CALLstatements cannot invoke stored procedures that return result sets because prepared statements do not support multiple result sets. Nor can the calling application access a stored procedure'sOUTorINOUTparameters when the procedure returns. These capabilities are supported beginning with MySQL 5.5.
User Comments
Be especially careful with the floating-point values in prepared statements when using replication. If a value is not a usual number but something like nan or -inf, it will be successfully stored as NULL on the server you're connected to, but replicated as "nan" (string) to the slaves, which will stop because of a syntax error.
Another issue is checksums of the tables. There are recommendations on the Web to check if master and slave are on sync comparing table checksums. However due to a limited floating point precision in ASCII SQL statements sent between master and slave (if query-level replication is used), the floating-point value on the slave is slightly different which results in a different table checksum.
Add your own comment.