Hello Artur,

Artur Anjos wrote:

> One small improvement will be deleting the file on application close, and
> creating again every time the application starts. :-)

yeah, the example i uploaded kinda shows the "brute force" aproach :-)
in real life, one would check whether there is the right version already
installed, if so, use it. if not, unzip it and use that one. and clean
it up after useage.

my first thought was not to unzip it to disk at all, but to load the dll
directly from a memorystream. unfortunatly i always ended up with the
LoadLibrary api, and that only accept filenames - or does anyone know a
trick to circumvent this? imho this would be the ideal solution, as then
the gds32 would only exist in memory, leaving no footprint at all on the
client machine...

>
>>One thing i'm really uncertain about is: what happens when two client apps
>>use this method with the same gds32.dll, but stored under different
>>filenames? i recall issues with Named Pipes for the FB *server*, are there
>>similar probs for the client??
>
> Good question!

yes, and as long as it's unanswered i still have my doubts... i'm not any
good in dll handling (i practically never use them). another point is that
FB 1.5 needs two dlls (gds32 and fbclient), i'll have to check to see if
that works, too. (or can i just use fbclient directly, "skipping" the gds32
wrapper?? maybe time to move over to fb-devel :-)

regards,
fingerman

--
-------------------------------------------------------------------------
when parsers parse, and compilers compile, then why don't objects object?

fingerbirdy - fingerman's door to Firebird
http://www.fingerbird.de