I'm using dynamic linking for my DLL's, so the EXE file doesn't care what
happens in DLL's. Each DLL contains TForm with IBO components. For example
one DLL is for creating payments, another is for currency conversions (it's
remote banking software).
Thare are no threads, but user can open multiple DLL forms at the same time,
so all 6 dataforms from different DLLs can be open.
Currently I'm creating new connection within DLL file, but it takes time.
Now I found out the possibility to share my single connection.
Before converting my application to connection sharing, I wonder what
pitfalls there may be (transactions, multiple users working with program,
etc.)

Riho-Rene Ellermaa
senior programmer
Hansabank

>
> > My application uses 6 DLL files which deal with different
> > data proccesing tasks.
> > What would be the expert recommendations - to use 6
> > different connections to database or to use shared handle
> > from EXE file. IMO, using shared handle is faster, because
> > you don't have to connect to database. But are there any
> > hidden problems?
>
> If you follow the advice for given by Borland for building DLLs
> (linking with the borlandmm.dll for memory management) your can do
> quite a lot with DLLs you just need to take the appropriate care.
>
> I have previously used DLLs with some success simply as a code/class
> storage mechansim. If the EXE instantiates a class from the DLL then
> you are using the DLL class and code but within the context of the EXE
> (provided you use the borland memory management).
>
> This approach as worked well for me in the past - including using
> forms defined in the DLL in with IBO (native) components, using the
> connection on the mainform from the EXE context.
>
> If you are doing multi-threading then things get more complex but the
> same principles apply.
>
> HTH
>
> Geoff Worboys