Reinier Olislagers wrote:
On 29/09/2014 17:41, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
On 29/09/2014 11:19, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
2. In businesslayer.pas, $define CRASH to see the problem.
The code in question is:

... so probably initialization order plays a part?!?

How should I fix this?
What happens if you move the responsibility for initialising and closing
the database connection to the app-level code? In other words, the app
does something like
As the demo indicates, that does work (undefine CRASH).

What I would like to know what is the cause of this problem - dlls being
loaded before some kind - what kind? - of initialization is complete?

Anyway, I'll keep digging; probably first looking at geting postgresql
support in anyway.
No, your example shows an implicit initialisation when the backend is
Agreed... but as that code works there's no reason to suspect your
approach won't work & my finished program sucesfully uses your approach ;)

Re bug report: agreed. I'll raise it.

Jose's comment about not (in effect) putting TIBConnection.Create() in the initialisation block of a program (hence of a DLL or .so) is interesting. Assuming that he is correct I think it's worth wondering /why/ he's correct, and if that is in fact a symptom of something wrong with the FPC initialisation sequence.

If he's correct, I'd expect the problem to persist even if your businesslayer DLL were loaded on-demand rather than at the whim of the OS: the binary state of the DLL/so in memory would be inappropriate for reliable operation.

If you still have problems when you call TIBConnection.Create() after all initialisation is complete, then you need to consider whether any state in the DLL/so has to be transferred to the main program. Hopefully you don't need to get involved with that.

A final thing to consider is that if there is an asynchronous element in database initialisation it could end up being difficult for the main program to check that the DLL/so was ready to use.

Mark Morgan Lloyd
markMLl .AT. .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
fpc-pascal maillist  -

Reply via email to