Paul Martin wrote:
> My point is not to debug my own code,
Are you certain that it isn't bugs in your code that are causing the
problem, then?
This is the first message I remember seeing on this list in the 2+ years
we've supported multiqueries that suggests that they just don't work.
Either you're the first to really use them, or your code has a bug.
> The endl's are used because the original multiquery example used them.
Ah. We had them in there only to make the preview() calls prettier.
I've removed them.
> I've just modified a simple example to show it break.
You haven't "shown" anything. You've just stated that "this is the
case" with no proof. What you posted doesn't compile and run, and
neither I nor probably anyone else is going to take the time to change
it until it does break, if only because you can't prove that something
_doesn't_ happen. It's up to you to prove that it _does_.
You have to meet us more than halfway on this. We're unpaid volunteers.
> I suppose I could use the sample db but that might not behave the same.
I addressed this in my previous email: if it doesn't behave the same,
that tells you something interesting and useful. It's a legitimate
troubleshooting step, totally separate from the matter of making it
convenient for people to test things for you on their machines.
> I have a feeling the engine isn't ready for another call for a short
> time,
Some of the biggest sites on the net run on MySQL. These sites see
normal loads of thousands of queries per second, and I assure you, they
don't have magic delays between every query. If that were necessary,
MySQL wouldn't have achieved its present popularity, and even if it had,
MySQL++ would either do this internally for you or tell you to do it in
the user manual.
> It looks like there may be a memory leak issue as well,
http://tangentsoft.net/mysql++/#memleak
