--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@...> wrote:

>
> > > curious, since when using embedded, you have successfully locked any
> > other
> > > potential user from getting access to your data file. Why are you
> > trying to
> > > shut it down?
> > > Alan
> >
> > Thanks again Alan:
> >
> > I ran IBPP's sample code, test6 is a function that backups and
> > recovers a database. Not two operations that naturally fit into one
> > function in my oppinion. But the code seems to work, and after the
> > call to ServiceFactory the next calls are to Service::Connect() and
> > Service::Shutdown().
> >
> > The backup and recovery functions are part of my firebird_utilities
> > library, and should handle any type of server.
> >
> > However, I really would like to get something working tonight (U.S.
> > West Coast) and I'll be happy if you can help me get something going
> > that depends on certain advantages offered by the single user nature
> > of the embedded server.
> >
> > I like IBPP, and now that I see IBPP has features that take
> > advantage of the service API, I'm interested in pursuing that
> > approach. Is this an appropriate forum for discussing IBPP issues?
> >
> > I'm also attempting non-IBPP Services API code, and I think I'll
> > start a sub thread that deals with my attempts to get that going.
> >
> > Thanks
> > Larry
> >
>
> no need to shutdown in the embedded environment. No need to disconnect
> either so there's no need to connect after backup.
> If you want to restore than that's another animal. You'll need to

disconnect

> from previous (old) file and connect to new one. In a remote setup

you may

> wish to
> I suspect shutdown filas in embedded since security is bypassed in the
> embedded and you need to be SYSDBA to shutdown a DB.

Thanks again Alan:

My IBPP backup seems to be working fine. I'd like to do the
recovery.

My first backup-recovery, based on command line interfaces to gbak,
was deeply flawed in execution. Those functions should have been done
with the services API. But they did work.

The recovery worked because it was built on a set of principles I
pulled from some guy's post in this forum. This is a set of comments
that is at the beginning of my recovery source, and I think it will
serve as a guide for a recovery built on the services API:

// Alan McDonald
// Firebird support forum
// Thu Jul 3, 2008 2:33 pm
//
// 1. ensure users are disconnected (force them if required by
stopping the
// service)
// 2. rename data file
// 3. start service again (users who try to connect get an error)
// 4. backup and restore to another alternate name
// 5. rename successful restore to original filename which will
immediately
// then allow users to reconnect (find the database file again.

My preference is to implement an IBPP solution, but I'm also trying
to get some samples from the Interbase API document.

The first thing I'd like to do is rename the database file, so I
call Database::disconnect(). But an attempt to rename the database
fails using MoveFileEx() fails with error code 32, "The process cannot
access the file because it is being used by another process.".

So how do I release the database file so it can be renamed?

Thanks
Larry