At 09:49 PM 22/07/2005 -0700, you wrote:

>Helen,
>
>Hmmm, actually I use C++ in this very large isapi web app, but you may be
>right
>about not comitting selects. I may not be insuring that. How long might
>FB wait
>before it determines a connection is dead?

It depends on the socket timeout setting on your server. On WinXP, I
believe it is 30 minutes by default - hearsay only, as I don't have WinXP.

>It is usually 30 minutes to several hours
>after the most recent web hit on the dev site that I try to do a restore.

What constitutes a "web hit on the dev site"? If you have an n-tier
system, your web app is presumably on line to the database until you
actually present a detach request. If you never do, then your server will
*always* have to wait until you shut down the web app and its connection(s)
time(s) out.

If you are running isapi modules, and not deliberately detaching them from
the database, then every instance will be subject to timeout shutdown. As
long as there is an instance still timing out, the db can't shut down. The
same is true where you have apps that do massive selects but never finish
fetching all of the output. That's the reason, of course, that table-style
components (including query-style components with unlimited select
statements) are most highly not recommended for client/server dbms's.

./heLen

>Kyle
>
>PS Thanks for the great book
>
>On 23 Jul 2005 at 11:42, Helen Borrie wrote:
>
> > At 12:17 AM 23/07/2005 +0000, Adam wrote:
> > >Kyle,
> > >
> > >Since it is a development machine, shutdown the FB service. If the
> > >connection is still active, it is just finishing up its garbage
> > >collection or something like that.
> >
> > Did you mean to say "shut down the database"? If you shut down the
> > service, you won't be able to run gbak...
> >
> > Kyle, simply having all your application instances call Disconnect doesn't
> > necessarily detach all connections immediately. If the client still
> has an
> > operation running in a transaction that wasn't committed before the detach
> > request was submitted, the server is going to have to wait for that
> > transaction to finish before shutting down the database. If a sweep or gc
> > thread was running, it will complete.
> >
> > If your application code is in the habit of requesting SELECTS without
> > committing them eventually, then there's a typical source of detach
> > delay. The server actually has to wait until it detects the dead
> > connection before proceeding to commit the transaction. (Since I know
> > you're a leading light of Delphi from waaay-back, I'd tend to suspect that
> > you might be using Autocommit transactions, which of course causes the
> > resources used by transactions not to be freed....)
> >
> > ./heLen
> >
> >
> >
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Visit http://firebird.sourceforge.net and click the Resources item
> > on the main (top) menu. Try Knowledgebase and FAQ links !
> >
> > Also search the knowledgebases at http://www.ibphoenix.com
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>
>
>http://pearz.com - A new whole-person approach to online dating
>
>
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Visit http://firebird.sourceforge.net and click the Resources item
>on the main (top) menu. Try Knowledgebase and FAQ links !
>
>Also search the knowledgebases at http://www.ibphoenix.com
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Yahoo! Groups Links
>
>
>
>