Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2003-10

MySQL 4.0 Files

12 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Johann Glaser

Hi!

Some months ago I developed a program using MySQL as backend database. This was MySQL 4.0 and therefore I used the MySQL 4.0 units. They have been stored in /usr/lib/fpc/1.0.6/units/linux/mysql/ver40/. This was with FPC 1.0.6.

Since then I updated to FPC 1.0.10. This doesn't bring these files any more. Why is this and what do you suggest to use MySQL 4.0 with FPC 1.0.10?

Thanks
Hansi

Johann Glaser Vienna University of Technology Electrical Engineering ____ http://www.johann-glaser.at/ ____

Reply by email

Michael Van Canneyt
to Johann Glaser
Johann Glaser wrote 9 lines
Hi! Some months ago I developed a program using MySQL as backend database. This was MySQL 4.0 and therefore I used the MySQL 4.0 units. They have been stored in /usr/lib/fpc/1.0.6/units/linux/mysql/ver40/. This was with FPC 1.0.6. Since then I updated to FPC 1.0.10. This doesn't bring these files any more.

It does. I didn't test the source package, but the CVS repository definitely contains the 4.0 units.

Why is this and what do you suggest to use MySQL 4.0 with FPC 1.0.10?

Please try CVS first.

Michael.

Reply by email

Johann Glaser
to Michael Van Canneyt

Hi!

Show quoted text 5 lines
> Since then I updated to FPC 1.0.10. This doesn't bring these files any > more. It does. I didn't test the source package, but the CVS repository definitely contains the 4.0 units.

Seems that they are forgotten in the fp-units-db Debian package.

Is it intended that the MySQL 4.0 binding is available in binary-only distributions (.rpm, .deb, .tar.gz)? If yes then I'll write an EMail to the .deb maintainer.

Bye
Hansi

Johann Glaser Vienna University of Technology Electrical Engineering ____ http://www.johann-glaser.at/ ____

Reply by email

Michael Van Canneyt
to Johann Glaser
Johann Glaser wrote 13 lines
Hi! > > Since then I updated to FPC 1.0.10. This doesn't bring these files any > > more. > > It does. I didn't test the source package, but the CVS repository > definitely contains the 4.0 units. Seems that they are forgotten in the fp-units-db Debian package. Is it intended that the MySQL 4.0 binding is available in binary-only distributions (.rpm, .deb, .tar.gz)? If yes then I'll write an EMail to the .deb maintainer.

They are available in source form only, not in binary form.

Michael.

Reply by email

Michael Van Canneyt
to Johann Glaser
Johann Glaser wrote 7 lines
Hi! > They are available in source form only, not in binary form. Ah, I see. That is why they are not in my .debs. Why aren't they distributed in compiled form too?

Because they have the same name as the 3.23 files. You can only have 1 binary copy at a given time - unless you want to start juggling with compiler search paths all the time.

In general I don't recommend using MySQL in FPC. The API fluctuates too much between minor versions, which can maybe be masked in C with some macros, but not in FPC.

Michael.

Reply by email

Florian Klaempfl
to Michael Van Canneyt
Michael Van Canneyt wrote 21 lines
On Mon, 6 Oct 2003, Johann Glaser wrote: >Hi! > > >>They are available in source form only, not in binary form. > >Ah, I see. That is why they are not in my .debs. > >Why aren't they distributed in compiled form too? Because they have the same name as the 3.23 files. You can only have 1 binary copy at a given time - unless you want to start juggling with compiler search paths all the time. In general I don't recommend using MySQL in FPC. The API fluctuates too much between minor versions, which can maybe be masked in C with some macros, but not in FPC.

Can't we include the MySQL version in the filename?

Reply by email

Michael Van Canneyt
to Florian Klaempfl
Florian Klaempfl wrote 24 lines
Michael Van Canneyt wrote: > > On Mon, 6 Oct 2003, Johann Glaser wrote: > > >>Hi! >> >> >>>They are available in source form only, not in binary form. >> >>Ah, I see. That is why they are not in my .debs. >> >>Why aren't they distributed in compiled form too? > > > Because they have the same name as the 3.23 files. You can only have 1 > binary copy at a given time - unless you want to start juggling with > compiler search paths all the time. > > In general I don't recommend using MySQL in FPC. The API fluctuates > too much between minor versions, which can maybe be masked in C > with some macros, but not in FPC. Can't we include the MySQL version in the filename?

We can, but at their release rate, we'll end up with a lot of files, plus everyone must edit all their sources to correct the version number.

Michael.

Reply by email

Rainer Hantsch
to Michael Van Canneyt

Hi!

I did not program very much with MySQL in FPC until now, but when I understand right, there are currently only three different MySQL unit versions. One is very old, one is valit up to 3.2, and then there is one for v4.0.

Why not handle minor differences within one and the same unit and use different filenames for the major versions?
So it will be relatively easy to use {$IFDEF} to choose different MySQL versions at compile time from the commandline!

On Tue, 7 Oct 2003, Michael Van Canneyt wrote:
| On Mon, 6 Oct 2003, Florian Klaempfl wrote:
|
| > Michael Van Canneyt wrote:
| > >
| > > On Mon, 6 Oct 2003, Johann Glaser wrote:
| > >
| > >
| > >>Hi!
| > >>
| > >>
| > >>>They are available in source form only, not in binary form. | > >>
| > >>Ah, I see. That is why they are not in my .debs. | > >>
| > >>Why aren't they distributed in compiled form too? | > >
| > >
| > > Because they have the same name as the 3.23 files. You can only have 1 | > > binary copy at a given time - unless you want to start juggling with | > > compiler search paths all the time.
| > >
| > > In general I don't recommend using MySQL in FPC. The API fluctuates | > > too much between minor versions, which can maybe be masked in C | > > with some macros, but not in FPC.
| >
| > Can't we include the MySQL version in the filename? |
| We can, but at their release rate, we'll end up with a lot of files, | plus everyone must edit all their sources to correct the version number. |
| Michael.
|
| _______________________________________________
| fpc-pascal maillist -
| http://lists.freepascal.org/mailman/listinfo/fpc-pascal |

mfg

Ing. Rainer Hantsch

.---------------------------------------------------------------------. | \\|// Ing. Rainer HANTSCH - Hardware + Software | | (o o) Service - Support - WEB-Design und Programmierung | |--oOOo-(_)-oOOo------------------------------------------------------| | Ing. Rainer HANTSCH | mail: | | Khunngasse 21/20 | www: http://www.hantsch.co.at | | A-1030 Vienna | tel: +43-1-79885380 fax: +43-1-798853818 | | ** A u s t r i a ** | handy: +43-664-9194382 UID-Nr: ATU 11134002 | '---------------------------------------------------------------------'

Reply by email

Michael Van Canneyt
to Rainer Hantsch
Rainer Hantsch wrote 8 lines
Hi! I did not program very much with MySQL in FPC until now, but when I understand right, there are currently only three different MySQL unit versions. One is very old, one is valit up to 3.2, and then there is one for v4.0. Why not handle minor differences within one and the same unit and use different filenames for the major versions?

There are no 'minor differences' - the API fluctuates too much.

So it will be relatively easy to use {$IFDEF} to choose different MySQL versions at compile time from the commandline!

No, because the distribution will only contain 1 version. Not all people install sources.

Michael.

Reply by email

Rainer Hantsch
to Michael Van Canneyt

On Tue, 7 Oct 2003, Michael Van Canneyt wrote:
| No, because the distribution will only contain 1 version. | Not all people install sources.
|
| Michael.

Yes, that's what I also do. I use only FreePascal without all the sources and classes.

But why not include at least two mysql units to the distribution, i.e. 'mysql_3' and 'mysql_4'?

This will allow developers to insert a

uses {$IFDEF MYSQL_4}mysql_4{$ELSE}mysql_3{$ENDIF}

and get hereby the option to choose the required mysql-unit at compile time!

Ok, there must happen some changes on the source code, but this is only required once.

mfg

Ing. Rainer Hantsch

.---------------------------------------------------------------------. | \\|// Ing. Rainer HANTSCH - Hardware + Software | | (o o) Service - Support - WEB-Design und Programmierung | |--oOOo-(_)-oOOo------------------------------------------------------| | Ing. Rainer HANTSCH | mail: | | Khunngasse 21/20 | www: http://www.hantsch.co.at | | A-1030 Vienna | tel: +43-1-79885380 fax: +43-1-798853818 | | ** A u s t r i a ** | handy: +43-664-9194382 UID-Nr: ATU 11134002 | '---------------------------------------------------------------------'

Reply by email

Bernhard Steffen
to Rainer Hantsch

IIRC, besides adding new data fields, they even changed the field order (!) in their communication structs between minor versions like from 3.22 to 3.23 - breaking the fpc mysql units every couple of month. Not very programmer friendly...

Rainer Hantsch wrote
But why not include at least two mysql units to the distribution, i.e. 'mysql_3' and 'mysql_4'? This will allow developers to insert a uses {$IFDEF MYSQL_4}mysql_4{$ELSE}mysql_3{$ENDIF}

that's what I tried when porting the old 3.21 (?) unit to version 3.23 some time ago. But you'll end up with a lot of defined at their release (and change!) rate ;-(

Bernhard

http://www.bernhard-steffen.de/

Reply by email