At 10:57 PM 20/04/2006, you wrote:

>Hi Helen,
>
>I'm using v4.5 and the TIBOBackupService and TIBORestoreService seem
>to work fine. I'm not creating the objects dynamically though; I'll
>try this. The Backup and Restore is performed by a DLL written for
>this purpose that can be used by multiple applications. All
>applications that use the DLL use cpLocal and all close their
>connections prior to calling the DLL. They do not, however, destroy
>their connection objects.
>
>You had mentioned something on the Firebird group that made me think
>you had concerns about using cpLocal. Would cpTCP_IP with server set
>to 127.0.0.1 be a better choice? If so, what's the difference?

The difference is that cpLocal is an application-level emulated
network connection that wasn't designed for multiple connections. It
works by sharing the inter-process communication space (memory)
between the server process and the client process. It's fine to use
it for single-machine development (the purpose Borland originally
intended it for) and it's fine to use it for embedded (where you have
no other choice and will be specifically blocked from attaching more
than one application). cpTCP_IP is a network connection. If you use
it with the localhost server, the network transport itself creates a
local loopback routing layer that is independent of the server and
client processes.

So, yes, it's not a good thing to be deploying applications that use
cpLocal with a full 1.5 server, especially if your users have access
to tools or you have routines that call the service manager, i.e.
service components.

Things change again in Fb 2.0, with respect to service manager calls
AND to cpLocal (which has been fully re-implemented to run across a
more robust sub-layer called XNET).

The separate issue - the one giving rising to non-closure of output
files - won't be resolved by fixing your connection strategy,
though. I'd recommend putting any server-level stuff into a separate
application that accesses the server through TCP/IP, does a task and
is then closed down. I assume you have other Admin functions, like
sweeps and statistics logging, that should also be put out of the way
of the minute-by-minute business of the data access app. I was
interested in the possibility that creating and destroying the
service object might solve the original problem, though, and still
would like to explore that, if I can just get IBOAdmin to behave
properly with IBO 4.6 (or vice versa).

If Jason is reading this, no, I haven't tested it with 4.6B because I
have that installed on Delphi 7, and Delphi 7 has been broken by the
latest Windows update. Haven't had time to reinstall IBO on D6
yet...haven't decided what to do about the Windows update either.

Helen