[fpc-devel]MySQL component installation

[Christopher Kirkpatrick]

On Sun, 2004-07-25 at 18:11, Michael.VanCanneyt at Wisa.be wrote:
> 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.

I agree, to a certain extent, with your comments, but MySQL is still the
most widely-used open source database; it is cross-platform and I am
sure there must be lots of database developers who would love to be able
to use Lazarus/FPC for MySQL applications. So, in order to maintain our
credibility as a comprehensive cross-platform development tool, I think
we need to be able to offer MySQL support. 

The other two databases you mention, though they undoubtedly have
advantages over MySQL, have not yet achieved the penetration of MySQL.
Firebird is truly cross-platform, but PostgreSQL still needs to have
Cygwin installed in order to run on Windows. (It's a bit reminiscent of
Borland's decision to use Wine to replicate the Delphi IDE in Kylix!
Though of course, in the reverse direction).

So despite its failings, I'm afraid we will need to provide some kind of
support for MySQL in the forseeable future. I'm willing to have a try at
producing some fixes, but they may not be elegant or comprehensive! In
the meantime, for my own purposes I shall explore the use of the
alternative databases.

Thanks for your comments.
Regards - Chris
> 
> 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.
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> 
> ________________________________________________________________________
> Doctors.net.uk e-mail protects you from viruses and unsolicited messages
> ________________________________________________________________________
-- 
Christopher Kirkpatrick <chris.kirkpatrick at doctors.org.uk>