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