At 05:31 PM 16/07/2003 +0100, you wrote:

>Hi,
>
>I've used .fdb extension since I began using XP and I see this behaviour
>with .fdb extension.

That's not encouraging.

>I planned to investigate this at some point - but havent done so yet and so
>also am unaware of
>exactly where it occurs - although it seems to be on first db access

The first db access is the one that triggers off the SystemRestore because
it's the one that opens the database file. The db file gets opened once
and only once.

> and gets longer as the database
>grows - the hd light stays on continously - and it seems to fo for long
>enough to have loaded all the
>pages in the database.

That because SystemRestore is a filesystem copy. So the bigger the file,
the longer it takes.

>But this does not happen every time it starts - but I have not seen a
>corelation between this and restarting
>windows but I havent been looking.

:-)

>Perhaps I am running a query which ends up needing to visit many pages in
>the db and these end up getting cached by
>OS

Database pages aren't "cached by the OS" - they are cached in the DBCache
by the server. The DBCache gets "emptied" when the server shuts down and
releases its resources.

>so removing the cost of loading these on susequent start up - I will need
>to investigate this to really find out.

You could save yourself a lot of effort by simply asking Ann Harrison about
it on firebird-support or firebird-devel. You'll HAVE to believe Ann. She
was the midwife at the birth of this DBMS.

> >In normal client/server mode, it's the server that opens the file and gets
> >the exclusive lock, so it will be the first user to log on who experiences
> >the delay.
>
>The database is only accessed by the app and there is only one instance of
>the app.

And only one connection. The embedded server doesn't accommodate multiple
connections.

>So when the app closes all the connections to the DB

there can only be one.

>(which I guess
>should occur on the server because the process owning the socket is closed)
>I guess it should cause the server to close the file - so in that respect it
>should be the same.

It's not the same. The embedded server closes the ONLY connection. The
normal server won't shut down unless there are no connections (which will
eventually be the case if a forced shutdown is performed).

>But when in client/server mode the server actually has a chance to close the
>file - whereas in embedded mode the server process just disappears - which
>is what led to my previous hypothesis.

Engage with Ann in a discussion of what the *server* does. And at least
explore the possibility that the disk-thrashing at startup has nothing to
do with the server and everything to do with the OS environment.

>I cant be 100% sure that it only occurs with embedded server though. Basicly
>I need to investigate this - I had just realised I had similar thing
>happening and that was what I though might be the cause.

Anyway, time for me to go to bed.

Helen