[fpc-devel]MySQL component installation

[Michael.VanCanneyt at Wisa.be]

On Sat, 24 Jul 2004, Christopher Kirkpatrick wrote:

> I have been trying to install the MySQLLaz package into my Lazarus
> system. It compiles OK, but on linking I get the following errors:
> 
> ...undefined reference to `mysql_connect'
> ...undefined reference to `mysql_create_db'
> ...undefined reference to `mysql_drop_db'
> 
> error while linking
> 
> This is because I have MySQL v4 installed in my Linux distro (SuSE 9.0
> or 9.1) and also WinXP, and the library no longer recognises these
> calls. I pointed out in my tutorial on the WiKi
> 
>  http://lazarus-ccr.sourceforge.net/index.php?wiki=LazarusDatabase
> 
> that changes had to be made to the fpc mysql unit (I used a re-named
> unit mysql_ver4) when creating simple applications to access late
> versions of MySQL. Although there are files for access to ver 3.3.2 and
> ver 4 in subdirectories of ($sourcepath)/fcl/packages/base/mysql, the
> units in component packages that use mysql have no mechanism to
> distinguish between the different versions. There is a file in each of
> the directories called mysql_version, but it only defines the version as
> a string, and doesn't do anything to modify the function calls.
> 
> In Version 4 of MySQL the function mysql_connect has been replaced by
> mysql_real_connect (now with 8 parameters instead of 4); mysql_create_db
> and mysql_drop_db have been deprecated in favour of issuing explicit SQL
> statements to perform the same function.
> 
> I think the mysqldb unit needs to have some conditionals (to take
> account of MySQL versions) inserted into the section of the
> implementation  dealing with these functions (unless I am missing
> something that is already there?).  I am prepared to have a go at making
> the necessary modifications, but am reluctant to do so if there is
> already some mechanism in place to cope with changes in version of
> MySQL, or if one of the original developers can do it better and faster.
> 
> We need to be able to define the version of MySQL - usually this is only
> done at link time by selecting the appropriate library. We are probably
> going to have to ask the user what version he's using before we compile.
> 
> Can I have some guidance please from the FPC developers?

The problem you point out is an old one. It is the very reason why I don't
recommend developing with MySQL in FPC. The API has changed quite often,
sometimes even a minor release would break FPC's units. In C, macro magic is
used to mask the incompatibilities.

This would not be a problem if the calls were the only things that changed.
Then we could solve the issues by dynamically loading the library and using
some internal procvars to call the correct versions.

The problem, however, is that the records used to describe connections and
result sets also change, and this cannot be solved in a dynamical way. This
is not a problem if they are 'opaque', then we define them as untyped
pointers. The problem is that you sometimes need to access the fields of
these records (e.g. to get the field count), and this IS a problem.

These issues can be solved with conditional compilation, but which version
should FPC distribute ? And when will it again be invalidated by some change
in the API of MySQL ? This is a maintenance nightmare...

My advice where FPC is concerned is to drop MySQL and use a better/stabler 
(API-wise) database, such as Firebird or PostGreSQL.

Doing so, gets you referential integrity, decent transaction support, and
stored procedures into the bargain...

That said, if you nevertheless want to have a shot at better MySQL support
for FPC, I'll do all I can to help.

Michael.