Delphi 2010, Connect to mySQL and Firebird database without lib dlls

2
votes

I am writing a portable application that connects to both a firebird database and a mysql database. I am writing the application in Delphi 2010, and using dbExpress components to connect to both databases. SQLconnection component uses dbxmys.dll and libmysql.dll for the mysql database, and dbxfb.dll and fbclient.dll for the firebird database.

On my development computer I had to move the dll files into /windows/system/. I think this is because of the system paths, in order to find the correct files and connect. I tried this on another client machine, and the software could not connect because the dll files were not found. Because this is a portable application I do not want to include a sub directory of the application directory to include the dll files, however I do not think the a client machine can run the applicaiton without having mySQL and Firebird installed and the pathing set correctly.

Is there a better way to do this? I have concidered making a sub directory and forcing my application to look there, (since firebird and mySQL can be installed anywhere) if they were included I would know for sure were they were at on any computer my app is launched from. But I don't really want to take this approach.

What are my options as far as direct db connection, or solving the dll requirement problem, I am not an experienced software developer. Thanks in advance.

Update: The DLLs are now in the same directory with the exe, and the application launches fine. I Still do not want to use any dlls. I have found a few components that do not require dlls, but they also require payment, finding another free option would be ideal.

1
mysqldelphi-2010firebirddelphi
Shared libraries are Good. My general preference is to keep any required .dll's in the same directory as your .exe. Please make sure about the licensing for any 3rd party dependency - regardless if it's source, dll or any other media. Don't assume it's freely redistributable with your app - always check. IMHO... - paulsm4
@paulsm2 Thanks for the tip about the licensing, I should be good in this case as this application is not for sale, and is for personal use. I will keep that in mind for the future. I think this is what I will have to do: is keep them with my exe's home dir, but I was hoping I would not have to. - user1868232
Again - shared libraries are Good. Slightly more complexity: much more flexibility (and, ultimately, runtime efficiency). But given the choice between "install directory" and "\windows\system32", my preference is generally "install directory". IMHO... - paulsm4

1 Answers

1
votes

What you can do is to store the .dll within the main .exe as zipped resources, then expand them in a local folder (local "Application data" for instance), and execute the library from there. Therefore, you do not need to put files in the system path (probably with administrator rights), nor change the path itself.

As a result, you do not need to copy the .dll with the .exe, and if the .dll are already available, your application will use them. The .exe folder won't be "polluted" by the library files, and your software could be still self-installing: if you copy the .exe in another computer, you still have the .dll within it, ready to be installed in an hidden local folder.

This is for instance how our SynProject tool use Hunspell libraries for spell checking. See this SO answer.