I thought DROP DATABASE would not work with the embedded server. I will try
it
tonight. Thank you for this suggestion.

I would still like my users to be able to move/rename/delete the database
once
I am finished with it, even if it is a scenario less important than
delete-after-raise
one.

I can understand this behavior is perfectly acceptable for an actual server,
where clients do not even know what or where the database files are, but in
my
application I need to distribute my data to clients and I need the embedded
database feature of Firebird.

I was hoping to find a way for the embedded database to close any open
handles on the file after I disconnect from the db. I would still like to
know if this
is a known issue or if someone else had this problem before or if I should
report
it to the developers on the bug tracker.

Thank you,
Timothy Madden.

On Wed, Aug 20, 2008 at 3:24 PM, Helen Borrie <helebor@...> wrote:

> At 19:14 20/08/2008, you wrote:
> >Hello
> >
> >I started use embedded Firebird 2.1.1 in my Delphi application (with
> FBLib)
> >and I need to create and populate a database file, but if anything goes
> >wrong, an exception gets thrown, I need to close and delete the database
> and
> >then prompt the user to try again.
> >
> >The problem is the embedded super-server keeps the newly created database
> >opened.
> >I use
> >gfix -force 1 -shut dbFile.fdb
>
> The command that deletes a database is DROP DATABASE (with no parameters).
> The server must be running and the owner must be connected to it, in order
> to drop it.
>
> >That is I use TFBLService.GFixSetShutdownDb(dbFile.fdb, 1), which is the
> >equivalent
> >API call in FBLib.
>
> What you have with embedded on Windows is a Firebird server and a client
> library running side by side in one application space, with no user
> authentication credentials. Since only SYSDBA can perform a database
> shutdown, it can't be expected to work with embedded, even if it made sense
> (which it doesn't). Database shutdown prevents new connections and new
> transactions. Since your instance of fbembed has exclusive access to the
> database, what would you be hoping for here?
>
> >The database file is still opened by the library after that. I even tried
> to
> >
> >FreeLibrary(hDLL)
> >
> [...]
>
> ...while the *proper* way is to disconnect from the database - or indeed,
> to ask the server to DROP the database, if that be your will. When the
> server drops a database, it deletes the file that the database lived in.
>
> >How can I create a database and then move it or delete it ?
>
> To delete it, send a DROP DATABASE request.
>
> You can't move a database within the context of a connection. You can move
> it as a FILE if it isn't open.
>
> >Is this a known issue ? Is this by design ?
>
> A database lives in a file but the server regards it as a database, not a
> file. To illustrate this, on more sophisticated platforms than Windows, a
> database doesn't have to live in a file. It can be a device in its own
> right, living on a raw disk partition that the filesystem doesn't even know
> is there.
>


>
>


>
>


[Non-text portions of this message have been removed]