Hi there,

TApplication.HandleException TMySQL50Connection can not work with the installed MySQL client version: Expected (5.0), got (5.1.49).

I'm getting this error when I try to connect to my db.

Free Pascal Compiler from SVN...
At revision 16002.
Lazarus from SVN...
At revision 27399.

I've never had this problem before. I did recently upgrade to Ubuntu 10.10 daily though. The box I'm on is the server and the client.

Any help would be greatly appreciated.

MySQL changes it's API call every version that is out, regardless how small that version is. So in order to provide the proper API you need to apply your code to specific MySQL version.

Personally I recommend everyone to stay away from this database: http://idkn.wordpress.com/2009/03/15/why-i-find-mysql-to-be-so-bad/

Ido

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100918/052882be/attachment.html>

No there was no problem a few versions ago. Someone had to change something that created this issue.

Anyone else???

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100917/67f20124/attachment.html>

Hello,

There is a new TMySQL51Connection component that is suitable for use with MySQL 5.1. Therefor, TMySQL50Connection now no longer supports 5.1 connections.

You should use the new TMySQL51Connection instead, but you'll need to recompile FPC and sqldblaz to see it on the component palette (I just committed the SQLDBlaz support for 5.1)

Michael.

Hi Michael,

I have a wrapper API for SQL Database access. I support MySQL by way of TMySQL50Connection. Since my system has the client and server at 5.1 and I can hard-code this new component so I don't throw the exception...

Will an exception be thrown for all users who try to use client/server 5.0 when the actual component is assigned as TMySQL51Connection? Is TMySQL51Connection backwards compatible to 5.0?

I'm hoping I don't need to expand my Database API to handle the many flavors of MySQL.

Thanks for your insight.

2010/9/18 Michael Van Canneyt :

No. That's not possible, because Mysql 5.1 isn't backwards compatible. That's what Ik tried to explain, and the reason you should stay away form MySQL. For 'normax' Linux distributions, this is not a problem, because they recompile everything that depends on MySQL if a new MySQL version becomes available (using the c-header file). So, you have to do that too.

A MySQL program has to be compiled for exactly the same version of the MySQL client-lib. It's sad but true.
Or you have to build a detection-mechanism for the client-lib-version (config-file), and use the appropriate TMySQLConnection.

(If you want to know more about the reason for this: it is very well possible that a 'varchar' field has an internal number of 5, and a 'integer' field a internal number of 6 in one version of the MySQL-client-lib. While those numbers are reversed in another version. So without knowing the exact client-version-number, you can not know what kind of field a field with internal number 6 is.)

I'm hoping I don't need to expand my Database API to handle the many flavors of MySQL.

You have. It's simple though, you only need another TSQLConnection.

Joost

What matters to Andrew (I think) is that all code will recompile as it was, the Pascal API has not changed. It's just a matter of doing

MyConnection:=TMySQL51Connection.Create(Application)

instead of

MyConnection:=TMySQL50Connection.Create(Application)

That is all that must be changed.

All other code will be oblivious to this change, if all code just assumes TSQLConnection (as it should). If you hardcoded TMySQL50Connection everywhere, then I suggest changing it to TSQLConnection with search and replace. All the rest should continue to work as-is.

We have a TSQLonnector component, which works more or less like the zeos connection component: you specify which connection type must be made, and it will create the appropriate TSQLConnection descendent and act as a proxy for that. There is still a bug, but if we can get it fixed, it would solve many of these version problems.

Michael.

Thanks guys. That is what I was afraid of. I did notice a few changes in the declarations and had to tweak my assignments for field creation statements (inside my api) when I did the upgrade to the DBMS. At the time I was using MYSQL5 component and it did not check for 51 at the time. But now that you have the 51 dedicated component I'll switch to that.

The API I designed made the assumption that the MYSQL5 component would connect to everything below that point. So the API does use generic SQL component (everywhere) however, and the specific is instantiated only at one spot in the API when they are created.

The problem is that b/c I assumed backwards compatibility the enumeration only features one per kind of native driver. Which means I'm going to need to expand my API to include at least 5 and 5.1. And when that happens an array of SQL statements will need to be provided as well :-(

The only good news is that SCS (product) has not been released. So no real harm done. Just more work has been realized.

But thanks for the clarification and help.

On Sun, Sep 19, 2010 at 6:24 AM, Michael Van Canneyt wrote:
On Sun, 19 Sep 2010, Joost van der Sluis wrote:

Thank you!

Dave Copeland.

dear fellows:

i am working with the Tdfb component with a lot of inexperience.

i have prepared an application to modify the fields def. and index def of a previus table with some information.

i have defined the new set of fields and indexes of the new table and i want to copy the information from the previus one to the new one.

i try tu use de copyform procedure described by the Manual but i have some trouble with this.

the command is tDestino.CopyFrom(tOrigen,ficheroDestino,false,7);

where tDestino is the name of the new Tdbf component and tOrigin is the previus name of the origin component.

the trouble is that when compile then create many new files.

i will appreciate any suggestion.

thanks in advance,

yours,

Ing. H?ctor F. Fiandor Rosario