Hi Ivan,

Sorry for taking a while to reply (I'm in the middle of moving house at
the moment!)

On Mon, 12 Dec 2005 08:57:11 +0100
Ivan Prenosil scribbled:

> > Open
> > ====
> > 1. Use isc_service attach to attach to the local service manager
> > 2. Use isc_service_start with action isc_action_svc_restore to
> > restore the file specified by the user in an open dialog to a
> > database in the system's TEMP directory
> > 3. Use isc_service_detach to detach from the local service manager
> > 4. SLEEP...
> > 5. Open a connection to the database
> >
> >
> > The problem is step 4 in the Open operation. If, after restoring the
> > database from the user-specified file I *immediately* open a
> > connection to it and start running queries I always wind up with
> > one of two errors:
>
> I think you are connecting to new database while the restore is still
> running. Services API is somewhat asynchronous, and just
> disconnecting may not be enough to wait for restore end.
> I would recommend to also use call to isc_service_query() to ensure
> the restore finished before disconnecting.

You're absolutely right! After digging around in the Firebird source I
found burp.cpp which seems to contain some gbak code, including a loop
which uses isc_service_query() to get the output from the service after
calling isc_service_start(). So I guess (at least in the case of a
backup or restore action), isc_service_start() fires up a separate
thread to handle the actual activity, leaving the calling thread free
to loop around calling isc_service_query() until the task finishes.

I haven't quite figured out all the bits of isc_service_query() yet
(the method for determining that the service has finished seems a bit
odd, and I'm sure I'm missing some error reporting / handling
capabilities), but it's certainly solved the pausing-before-open
problem so the application is backing up and restoring the embedded
database successfully.

Anyway, thanks again for the quick responses, and for pointing me in
the right direction!

Cheers,

Dave.