--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> At 06:17 AM 11/01/2007, you wrote:
> >--- In firebird-support@yahoogroups.com, "Sean" <firebird_tmc@> wrote:
> >
> > > > >Copy a new firebird DB and start the application to connect

to the DB

> > > > >in embedded embedded mode, sometimes it gives an error of "i/o
> >error".
> > > > >If I run the application again, it works fine since then. Seems
> > > > >something was rectified after 1st failure.
> > > > >
> > > > >Not sure if it is caused by the way I created the database.

Here are

> > > > >the steps:
> > > > >1. generate SQL from my development DB.
> > > > >2. Run SQL to generate an empty database
> > > > >3. Open the empty database in IBExpert in superserver mode, run
> > > > >another sql to create some pre-defined records, the close the DB
> > > > >connection.
> > > > >
> > > > >Unfortunately I cannot duplicate the problem. For one same
> >database it
> > > > >may have problem on one computer, but works fine on another

one...

> > > > >
> > > > >Does anyone have a clue?
> >
> > > After running the script, Script Executive asks "There are

uncommited

> > > statements. Commit them?". I always answer yes. Then I disconnect
> > > from the database and copy the database file out.
> > >
> > > I notice that after I disconnect from database, the fbserver.exe

still

> > > hold a handle to the database file. If I copy the db file with the
> > > handle open, is that a problem?
>
> Yes, it can. Apart from the possibility that the file image may be
> incomplete because a transaction has not finished committing, many
> file-copy programs take locks on the file (or on some lower-level
> blocks of disk) which can get in the way of any uncompleted work.
>
> Superserver also has an exclusive lock on any database file that is

open.

>
> >Here are more info that I got just now. Hope this can be useful:
> >
> >1. The error message is: operating system directive CreateFile failed
>
> This could be coming from your copy program, if it can't open the
> database file due to the fact that Superserver is still busy, e.g.
> committing work, updating indexes, etc. IBExpert is just a client
> application. "Closing the connection" in IBExpert simply sends a
> detach request to the server. It doesn't shut down the database. If
> IBExpert was the only connected client then, eventually, when the
> server has finished executing its requests, it will close the file.
>
> I don't know how you determined that a database handle was still
> active....but, if a database handle was active then the database file
> was open and therefore locked. Hence the I/O error if you tried to
> copy it at that point.
>
> If, on the other hand, you succeeded in copying the file and then
> found you got the I/O error when you tried to connect to the copied
> database through the embedded server, the boot is on the other
> foot. Embedded is Superserver and *it* needs an exclusive lock in
> order to open the database file. If the filecopy program was still
> busy writing to the file (or hadn't yet gotten around to closing it)
> the embedded server would be denied a file handle and you would get
> an I/O error then.
>
> There could be other reasons why an I/O error could occur, e.g. the
> embedded server can't find anywhere to write temp files for a sort,
> etc. If it works on some systems and not on others, then you'd need
> to study how the conditions differ. This file-copying thing is
> fairly crazy (IMO), especially if you are running the embedded app as
> a service. Anything you do to a database file outside of a server's
> control is a source of potential problems...why are you doing it

this way?

>
> Why not build a deployment database on your development machine and
> deploy it as a gbak backup? Then your installation script can start
> by running a restore to create the new database in the place where
> the embedded app expects to find it.
>
> ./heLen
>

Thank you for the suggestion. I will change to use gbak to prepare the
database. Let's see how it works...

BTW, I used Process Explorer from sysinternals.com to look for the
process holding a handle to the fdb file.