[odb-users] Question about packaging the generated code for each database into a separate dynamic-link library

[Marcos Gonzalez Menendez]

Hi,

I'm following the steps that are described in the manual for packaging the
generated code into separate dll's.
Following the example that is explained in the manual, odb.exe has already
yielded:
- person-odb.*
- person-odb-pgsql.*
- person-odb-sqlite.*

The problem is that I would need a better explanation about the following
manual paragraph:

"The second step in packaging the generated code into DLLs is to decide
where to place the gener-
ated common interface code. One option is to place it into a DLL of its own
so that we will end
up with (replace *.dll with lib*.so for Unix): person.dll plus
person-sqlite.dll
and person-pgsql.dll, which both link to person.dll, as well as person.exe,
which
links  to  person.dll  and  dynamically  loads  person-sqlite.dll  and/or
person-pgsql.dll. If this is the organization that you prefer, then the
next step is to build
all the DLLs as you normally would any other DLL, placing person-odb.cxx and
person.cxx into person.dll, person-odb-sqlite.cxx into
person-sqlite.dll, etc. Note that in the pure dynamic multi-database
support,
person-sqlite.dll and person-pgsql.dll do not export any symbols."

I have the followind doubts:

- Does person.dll contain only person-odb.* code?
- Does person.dll export any symbol?
- Does person-sqlite.dll contain only person-odb-sqlite.* code?
- Does person-sqlite.dll export any symbol?
- Does person-sqlite.dll ling to person.dll?
- Does person.exe need a LoadLibrary call for loading person-sqlite.dll?
Coudl you give me an example of this?

Thanks in advance for any help you can provide
-- 
Marcos González Menéndez