mysql++ alternative?

[Red Squirrel]

Is there an alternative way to connecting to mysql dbs?

I'm really growing tired of how mysql++ is so sensible.

ex: you call fetch_row once too many it crashes. You don't call it often enough, next query crashes with sync error. There seems to be no real way to get the number of rows returned without doing a count() but if the returned set is 0, then guess what, when you call fetch_row, it will be one time too many and, crash.

Lost mysql connection? Crash. It's just too crash sensitive imo. I rather let it fail so I can handle the error instead.

[marceln]

Have you tried MySQL ODBC Connector or MySQL C++ Connector?

[Red Squirrel]

Hmm I'll have to check mysql C++ connector. I forgot about that one. Not sure why I did not pick that one right off the bad considering it's straight from Mysql themselves.

It is platform inderpendant right?

[marceln]

It is platform inderpendant right?

Sure seems so, from the documentation.

[Paul McKenzie]

Is there an alternative way to connecting to mysql dbs?

I'm really growing tired of how mysql++ is so sensible.

Are you using the latest stable version?

http://tangentsoft.net/mysql++/

ex: you call fetch_row once too many it crashes. You don't call it often enough, next query crashes with sync error. There seems to be no real way to get the number of rows returned without doing a count() but if the returned set is 0, then guess what, when you call fetch_row, it will be one time too many and, crash.

Unless you have proof it isn't your code that's causing the problem, or if you are not running the latest version on the MySQL++ site, then I have issue with anyone saying that "this software doesn't work", when there is no discernable proof that it's the software.

I have been (and in some cases still) an independent software developer. One thing that should never be done is impugn or imply that there is something wrong with the software if the proper proof has not been given. How would you react if you went on a forum, and saw someone trashing your software with no proof that it is the software's fault? Or at the very least, contacted you to ask further questions or open a bug ticket?

Others are reading this thread, and if they were going to use mysql++ in their own applications, they are immediately given the notion that mysql++ is faulty, when we have no proof as to what you're saying is true or not.

Lost mysql connection? Crash. It's just too crash sensitive imo. I rather let it fail so I can handle the error instead.

Have you contacted the author? If not, why not? If so, have they helped you?

Regards,

Paul McKenzie

[Red Squirrel]

You have valid points. The issue with mysql++ is also the fact that it's not really supported. There is no forum or anything. Mail lists dont count. Those are a very messy medium for support. I fail to understand why some sites even use those over a forum, which is easier to setup and maintain.

Think if it had a support forum I'd post there about the issues and see if there is a fix or a way around it. There's some documentation but it does not go into any of the details of how to properly execute a query. It could possibly be I'm doing something wrong but I'm just going by the little documentation I have, which is basically just the class prototype with brief information of each function.

edit: I just checked and it actually looks like it's kept up to date at least. I find lot of these projects are often not updated so at least this one is. I was at 3.0.6 and 3.0.8 is latest so I'll try to update and see if it helps my issues.

[Paul McKenzie]

You have valid points. The issue with mysql++ is also the fact that it's not really supported. There is no forum or anything. Mail lists dont count.

Did you try and leave a question there?

Also, as with any API-type software, the author or whoever is there to help you is looking for the smallest, complete piece of code that duplicates the problem. This eliminates any issue that you may have introduced due to improper coding such as memory overwrites or other issues not related to the API.

Regards,

Paul McKenzie

[exterminator]

I am not ignoring your frustration. It's understandable.

ex: you call fetch_row once too many it crashes. You don't call it often enough, next query crashes with sync error. There seems to be no real way to get the number of rows returned without doing a count() but if the returned set is 0, then guess what, when you call fetch_row, it will be one time too many and, crash.

Lost mysql connection? Crash. It's just too crash sensitive imo.

But it's like saying, you access an element beyond the array's last element and it crashes. :-)

If you can take the pain then probably write your own wrapper over their APIs. And then you can try to make your wrappers as suitable to you. But you will have to write robust code.

For example, if you do face regular unavailability of the database which makes the connection get lost or go bad, you should try to test the connection being alive before running any query against it. I am sure there must be an API with mysql++ to check the current connection status.

About trying to retrieve one column too more, probably, that's just your mistake as you should be only trying to retrieve as many fields as you asked for in the select query.

About fetching not enough and causing failure of next query, I think that you should handle in your code (or your wrapper) where in you flush the result set before you go on to execute the next query. How that flush will happen with mysql++, try to search the documentation, or their mailing list.

The same way some of the Sybase DB APIs work too. But once you get adept to the way they work, you should be going ahead freely!

Hope you get over your frustration soon and try to resolve the issues writing more robust code. Also, never hesistate in contacting the folks at their mailing lists but provide them sufficient information to replicate the problem and probably they will suggest better answers. Importantly and advantageously, you might get aware of some of the APIs that are standard enough in their use across applications that you might not be aware of or might help you check the pre-conditions better and help make your application run more reliably. Good luck.

[GCDEF]

I'm really growing tired of how mysql++ is so sensible.

Those sensible APIs are really annoying.

[exterminator]

Those sensible APIs are really annoying.

Probably, he meant 'sensitive'. Kind of like, 'touch-me-not' (mimosa pudica).

[Paul McKenzie]

I am not ignoring your frustration. It's understandable.But it's like saying, you access an element beyond the array's last element and it crashes. :-)

Thanks exterminator, that is exactly my point.

An API can go so far in "hand-holding" the programmer. I'm sure I can crash a Windows app by just calling the Windows API functions without checking return codes, or supplying the wrong parameters, or even supplying the right parameters but not checking that certain other functions all were successful, etc.

For example, I have written API's, and I can't tell you how many times a function that requires a pointer to a long variable makes the programmer do this:

long *ptrLong;
MyAPI(ptrLong);

Then they complain to me or my associates that the program crashes, when all along they should have done this:

long myLong;
MyAPI(&myLong);

No matter how clearly this or other things are stated in the documentation, we have naive programmers making the first mistake. This is why API-type software is designed for the intermediate-advanced to advanced programmer -- it isn't designed for the beginner or the "dabbler" in the language the API is designed for. Mistakes like the one above is just one example why this is the case.

Regards,

Paul McKenzie