Situation
I install MySQL 4.1 and ZEOSDBO and make a quick app which tries to connect to MYSQL
On startup I get the error "No dynamic library from the list libmysql41.dll found"
I get this with TZConnection.protocol set to mysql or mysql-4.1
Ok I reread the installation guide and realize I could copy the libmysql41.dll that comes with ZEOS to my system path somewhere
I also other two other options to fix this
1: rename libmySQL.dll that comes with MySQL to libmysql41.dll
2: Compile ZEOSDBO with MYSQL_STRICT_DLL_LOADING undefined
Why does ZEOS comes with its own set of MySQL dll's? I would of thought it would be better to use the libmySQL.dll that came with the MySQL the code was running against.
The comment for MYSQL_STRICT_DLL_LOADING says "Prevents loading default libmysql.dll" Apart from situations of multiple versions of MYSQL why would you want this? And why is this defaulted to defined? Wouldn't using libmysql.dll be the more common scenario.
I would also have thought setting the protocol to mysql(which I presume means 'work with all version') would allow it to work with libmySQL.dll even with MYSQL_STRICT_DLL_LOADING defined.
My target environment could be using any MySQL 4.x version
Can't find libmysql41.dll
Moderators: gto, cipto_kh, EgonHugeist
Can't find libmysql41.dll
Delphi 2005
zeosdbo-6.5.1-alpha_cvs_13-10-2005
mysql-4.1.15
zeosdbo-6.5.1-alpha_cvs_13-10-2005
mysql-4.1.15
DLL
Hi,
Set your global or user PATH (environment variables)! If this PATH contains your directory which contains *.dll, it will work!
Attila
Set your global or user PATH (environment variables)! If this PATH contains your directory which contains *.dll, it will work!
Attila
Thats pretty much the same as the install instruction:
Copy files to path or point path to files amounts to the same thing.
The point is I dont want to distribute any DLL's with my app and since MYSQL is installed on the target machine I shouldn't have to.
Copy files to path or point path to files amounts to the same thing.
The point is I dont want to distribute any DLL's with my app and since MYSQL is installed on the target machine I shouldn't have to.
Delphi 2005
zeosdbo-6.5.1-alpha_cvs_13-10-2005
mysql-4.1.15
zeosdbo-6.5.1-alpha_cvs_13-10-2005
mysql-4.1.15
-
matsgefvert
- Junior Boarder
- Posts: 38
- Joined: 22.11.2005, 09:11
- Location: Skövde, Sweden
- Contact:
The problem with libmysql.dll is that there are incompatibilities between version 3.23 and 4.0, and there really isn't any good way to tell them apart (as far as I know).
When we upgraded from ZeosDBO 5.4.1 to 6.1.5, we simultaneously made the shift from libmysql323.dll to libmysq40.dll, which meant that we had to maintain two branches, one for each version. This meant endless frustration because trying to run a program that requires the 3.23 version, but got the 4.0 version, and vice versa, would invariably crash (yes, it's that bad).
Coupled together with my installation of php5 (which required the 4.0) gave me a serious headache until I finally bit the bullet and copied libmysqll.dll into each and every folder for each program, so they would always have the correct local copy.
IMHO, it was a pretty dumb move of the MySQL developers to introduce these incompatibilities into the library. ZeosLib takes what I think is probably the best solution under the circumstances and physically tells them apart by way of renaming them.
If you're absolutely sure that you will run off of a specific version of libmysql, go ahead and set MYSQL_STRICT_DLL_LOADING to false.
When we upgraded from ZeosDBO 5.4.1 to 6.1.5, we simultaneously made the shift from libmysql323.dll to libmysq40.dll, which meant that we had to maintain two branches, one for each version. This meant endless frustration because trying to run a program that requires the 3.23 version, but got the 4.0 version, and vice versa, would invariably crash (yes, it's that bad).
Coupled together with my installation of php5 (which required the 4.0) gave me a serious headache until I finally bit the bullet and copied libmysqll.dll into each and every folder for each program, so they would always have the correct local copy.
IMHO, it was a pretty dumb move of the MySQL developers to introduce these incompatibilities into the library. ZeosLib takes what I think is probably the best solution under the circumstances and physically tells them apart by way of renaming them.
If you're absolutely sure that you will run off of a specific version of libmysql, go ahead and set MYSQL_STRICT_DLL_LOADING to false.
matsgefvert, I agree: The best practice is to deploy the correct DLL in tehe same folder as the application. But If you have additional apps (like tools), then this is a problem - my practice is to create da C:qLib and have all the necessary DLLs in the same folder (and add it to PATH variable). If an application needs a different version of the DLL, then I deploy it with the app. It's far from perfect, but works for me.
-
matsgefvert
- Junior Boarder
- Posts: 38
- Joined: 22.11.2005, 09:11
- Location: Skövde, Sweden
- Contact:
Well, when we deploy our applications on a target computer it's easier because all our files are in one directory only. But on a developer machine it's a bit tricky because all the projects are in different subfolders and each of them need to reference a particular libmysql.dll... 
Coffee clarifies the mind, improves morale, lifts the spirit and motivates and inspires to focused, productive work.