Zeoslib Portal

Zeos8 r7018 Android won't compile !!!

-V -VN --description:"Zeos Plain Database API" -NO.\Android\Debug ZPlain.dpk
[DCC Error] ZPlainLoader.pas(203): E2003 Undeclared identifier: 'LoadLibraryEx'
[DCC Error] ZPlainLoader.pas(203): E2003 Undeclared identifier: 'LOAD_WITH_ALTERED_SEARCH_PATH'
[DCC Fatal Error] ZPlainDriver.pas(705): F2063 Could not compile used unit 'ZPlainLoader.pas'
Failed

Michal

Now it's compiling - Zeos8 r7019

Michał

@both constributors,
i just added a fallback using a define. I'm not aware how to resolve the issue on other platforms except using the default code. Let's wait for a new ticket or forum thread. Anyway thank's for your help and support!

@Egonhugeist,

Which platform was missing it except Android? My original idea was to define the LoadLibraryEx method for these (if they have it) or create one, pointing to the original LoadLibrary method.
Anyway, conditional splitting is also fine if you know which platforms need the extra care :)

Hi Michael,

Lazarus 2.0.6-64 on Linux(x86) had no problem with build r7018.
Only Delphi 10.3.3 with Android had a problem.

Michal

I've tested the fix (latest r7020) on all my drivers and it seems to work perfectly, completely solving the original problem. I tested:

Oracle clients (11, 12, 19)
PostgreSQL
MySQL
Firebird

Tested on both 32bit and 64bit, Windows 10, Delphi 10.4. Thanks for the fix!

-Mark

@Mark, thanks for confirmation! That's allways helpful.
@aehimself all platforms except UNIX such as
DARWIN (OSx)
ANDROID [ANDROID32,ANDROID64]/Delphi AARACH64/FPC
etc.

so it's not worth it bypassing the issue by reimplementing the Windows idea of LoadLibrayEx.
As i said: We're happy the issue is resolved and i perfectly can live with the {$IF declared(LoadLibraryEx)} define. The more FPC has its own DynLib unit(added to Zeos by Marco Van De Voort/FPC core) and i wouldn't take a look to all the hidden FPC .inc files(compile target related) as long nobody reports similar problems.
From my side the case is close and i thank you all for your support!

MJFShark wrote: ↑29.10.2020, 12:28I've tested the fix (latest r7020) on all my drivers and it seems to work perfectly, completely solving the original problem.

Good, happy to hear! And with your request a 3 year old bug report was closed, so thank you! :)

EgonHugeist wrote: ↑29.10.2020, 19:33DARWIN (OSx)
ANDROID [ANDROID32,ANDROID64]/Delphi AARACH64/FPC
etc.

Expected. I only have Delphi Win32/64, I relied on Zeos tests to reveal any compile/behavior breaks. So.... FPC/Lazarus doesn't have LoadLibraryEx? That's a shame. It would worth to define it (even in the same unit) on Windows platforms or else FPC will be still affected by the exactly same "misloading" as Delphi was, before.

EgonHugeist wrote: ↑29.10.2020, 19:33and i wouldn't take a look to all the hidden FPC .inc files(compile target related) as long nobody reports similar problems.

Understandable. Zeos is pretty old and pretty large. Noone wants those wardrobes open, just to release a ton of skeletons!!!

EgonHugeist wrote: ↑29.10.2020, 19:33From my side the case is close and i thank you all for your support!

As I already mentioned I feel really good if finally I can give something back to this awesome component. Special thanks to Mark for the ExpandFileName tip!

But not so fast! There is one question left for you, Michal.

aehimself wrote: ↑26.10.2020, 19:58On the other hand keeping the libraries opened until the end of times is NOT a good solution, I don't like this in Zeos either [...] I'd expect it to be released when the (last) connection is disconnected which is using this library.

Do you think it could be done?

aehimself wrote: ↑29.10.2020, 20:58 But not so fast! There is one question left for you, Michal.

aehimself wrote: ↑26.10.2020, 19:58On the other hand keeping the libraries opened until the end of times is NOT a good solution, I don't like this in Zeos either [...] I'd expect it to be released when the (last) connection is disconnected which is using this library.

Do you think it could be done?

lol - that sounds like a feature for Zeos 9.0 - or maybe a bugfix for a later 8.x version

@aehimself,

of course it can be done. Yet it has a low priority for me. Propose you open a feature request ticket: https://sourceforge.net/p/zeoslib/internaltickets/ so we won't forget it.

I just wanted to chime in and mention that since the fix to the dll loading stuff I don't have an actual need for unloading the driver dlls. I really brought it up in case it was something that already existed or something I could use to diagnose/workaround the loading issue. Thanks, as always!

-Mark

MJFShark wrote: ↑03.11.2020, 17:22I just wanted to chime in and mention that since the fix to the dll loading stuff I don't have an actual need for unloading the driver dlls.

I'm sorry to say this, but it's not about you, nor your request :) It's a really inconvenient way of optimization (?) to keep the library connections open until the application is closed. I don't know how it is being handled, but if a new handle is opened each time a connection is opened but not closed afterwards, your application will crash due to handle / memory outage if it is connecting / disconnecting rapidly.

For me it's annoying because if I want to update library DLLs I have to close my app down.

But yeah, this is something I'd LOVE to see in Zeos.

> I'm sorry to say this, but it's not about you, nor your request
My wife said the same thing!

-Mark

aehimself wrote: ↑03.11.2020, 20:45But yeah, this is something I'd LOVE to see in Zeos.

Added to the wish list: https://sourceforge.net/p/zeoslib/wiki/Development objectives for Zeos 9.0/

aehimself wrote: ↑03.11.2020, 20:45I don't know how it is being handled, but if a new handle is opened each time a connection is opened but not closed afterwards, your application will crash due to handle / memory outage if it is connecting / disconnecting rapidly.

No matter how many times LoadLibrary is called, Windows only loads single instance of a lib. Different handles just point to the same object. Moreover, FreeLibrary cares about ref counter as well. So it's enough for driver object to call FreeLibrary on destroy.