Really? Well, that's nice! I'm just not used to the thought of leaving something to chance

By the way, I found this article:

MySQL C API Multiple Statement Execution

As I understand, if it executes more than one query at the same time, it produces many different result sets and you have to go through them, but this kind of function is not included in this DLL Well, I guess I just have to go with it and hope there will be no multiple queries.

I don't see it as an issue of chance rather as an issue of timing.

Consider that in a poker game, people will change the world state on the order of seconds and minutes and not milliseconds. The world state in your game example means changing a card, folding, bluffing, ante-ing, hitting, etc... none of these actions are very fast in terms of the SQL database application and thus there is very little to no chance of concurrent queries being inconsistent.

Hence, In My Humble (and admittedly ignorant) opinion, while you may feel that this is leaving things to chance, in actuality even 100 function calls to a MySQL engine in a second (representing 100 functions, representing 100 tables) is child's play compared to what MySQL can do.

At least I got that off my chest Right now, I'm copying the results of the query into separate local strings immediately after it's execution. With the addition of this, I hope it will really be impossible for my worries to become true.

It sounds like you are creating a "queue" system for you mysql queries. If so, this is a good thing since while I believe that the timing nature of your game makes it so you don't have to worry about inconsistent queries, a queue system makes your game all the much safer!