I tried to implement a prepared statement using MySQL and recieved a message stating the DB was unsupported. From the documentation is looks like it should be supported?

Sorry for the delay on this - I've been somewhat swamped since getting back and somehow overlooked it. I just confirmed that it works ok with the 1.4.134 connector for Windows, but indeed, I get the same error when trying it with the 1.4.138 connector Linux. Am investigating...

The "unsupported DB" return error is a mistake. (The internal MySQL error code happens to be 1, same as ASQLERR_BADDBMSID; the code was failing to translate it to ASQLERR_DBMSERR.)

However, I haven't been able to figure out the cause of the real error, which is "unsupported buffer type" in the binding structure when there are more than 2 fields being bound. I've tried using all strings, and have logged the entire bind structure before and after the binding operation, and don't see any corruption or explanation for the problem or why it behaves differently under Windows than Linux.

The MySQL client library version is newer on my Windows system - 5.1.50 vs 5.1.34 on the CentOS 5.7 system, so I suppose it is possible that it was something fixed in an update. (The latest is 5.1.72).

Unfortunately, the packages available from MySQL are organized somewhat differently than the ones included in CentOS, so I'm not sure what kind of chaos uninstalling/updating will lead to. What version of the client library do you have? (It displays in SQLTEST1).

SQLTEST1 report 5.1.34

I've actually upgraded my MySQL CentOS .rpms to 5.5.32 via the remi 3rd party CentOS yum repo. I've shared a google doc with the steps to upgrade to that. This is a CentOS 64-bit server though, so I think the client that's used by A-Shell is the 32-bit stuff I copied over before, so it's not using the latest client that's installed.

I'll dust off my CentOS 5.9 32-bit instance tomorrow and see if I can get it to use the newer client library.

I just isolated the problem to a change from the libashmysql.so.1.4.134 to 1.4.135. (You can download all the versions from http://www.microsabio.net/dist/other/asql/ ).

That suggests that updating the MySQL package isn't the issue, although on the other hand, the change in 135 was a Linux-only workaround (for a problem you reported) which appeared (to me) to be a similar kind of inexplicable corruption occurring within one of the mysql API routines. In that case I was able to code around it by using alternate API routines, but I'm not so sure there are any alternate API routines for the binding operation, but reviewing the changes may help me dodge the issue by some other means.

Most of the other changes (136,137,138) are just tracing improvements. I didn't move any of the code back to the Windows version because it seemed stable and didn't have the original problem (nor this new one).

I've got a lot of people waiting on various things at the moment, to I may not be able to get to this until the weekend sometime. If you do update your MySQL in the meantime, let me know how it goes; I may want to do it as well.

FYI, I haven't had time to try to upgrade the client library that A-Shell is using. Also, I deleted my 32-bit instance sometime back, so unfortunately I can't dust that off.

I'll try to get back on figuring out a workaround...

jack is this possibly the problem i am having with stored procedures not working? did you ever figure out the problem here?

thanks

Obviously this thread is a bit stale, and it's not clear to me if the problem was resolved or not.

The one overlap that I can see is that the error code is misleading/wrong. There is an error, but it's not being translated correctly.

Let me go back to your original thread calling stored procedures to address it further.