Subject | Re: [Firebird-Architect] Shutdown Call, take 2 |
---|---|
Author | Jim Starkey |
Post date | 2004-05-06T14:45:25Z |
Paul Reeves wrote:
database parameter block item that can only be used on attach database.
The call I'm proposing applies to the Y-valve and all providers. It's
primary use is in a server, but may also be used in any embedded
application, or for that matter, any application that needs a global
mechanism to shutdown all database connections.
I'm not the least bit hung up on the name of the call, but I hesitate to
make it "fb_shutdown_server" because it applies locally, not to a server
that the process may be connected to. "fb_shutdown_connections" perhaps?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>We also have a semantic problem. Traditionally (if that is the right word)The mechanisms are quite different -- the existing mechanism is a
>shutdown in InterBase closes the database from non-SYSDBA connections,
>but keeps the server and database online for maintenance by SYSDBA.
>
>In Windows, with the advent of SS, shutdown is used in some contexts to
>mean 'kill the server process' and to hell with any open connections.
>
>This new call, in its current format seems to be server oriented, not
>database oriented so it would seem to extend the second context while
>adding even greater confusion to usage of the first.
>
>Of course, the former context is inappropriately named and I suspect
>almost everyone of us has been caught out by it at some time or other.
>
>
>
database parameter block item that can only be used on attach database.
The call I'm proposing applies to the Y-valve and all providers. It's
primary use is in a server, but may also be used in any embedded
application, or for that matter, any application that needs a global
mechanism to shutdown all database connections.
I'm not the least bit hung up on the name of the call, but I hesitate to
make it "fb_shutdown_server" because it applies locally, not to a server
that the process may be connected to. "fb_shutdown_connections" perhaps?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376