Reinier Olislagers wrote:
On 28/09/2014 13:54, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
But when your code modifies strings in the context of the database
library they're preallocated C-type strings, i.e. can't be extended or
shrunk so don't make unexpected reference to any memory manager.
Yes, I agree. However, this problem should also appear in regular FPC
applications + Firebird library, right? Why don't I see any problems there?
As mentioned, I'm using regular sqldb to talk to Firebird, nothing special.
Interesting. So if I understand you correctly it's only when you've got
two levels of dynamically-loaded library, i.e. one DLL is responsible
for loading another.
Yes. When/if I add Postgresql support we may now more ;)
Now would probably be a good time to try Postgres as an alternative.
Ah, a mind reader ;)
I think the first thing I'd try is a trivial program+DLL checking that
the DLL can initialise a database library, in case there's something
wrong with multistage initialisation.
If I understand things correctly, your app is linking to the custom
library as part of the program-load operation handled by the OS, but the
custom library is opening the database library dynamically. It might be
worth checking this latter part with utter paranoia, my recollection is
that the FPC loader library now saves any error message returned by the
OS and I've found this useful in the past.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
