Subject | Re: [firebird-support] Listing Databases on the Server |
---|---|
Author | Helen Borrie |
Post date | 2006-12-08T04:23:55Z |
At 01:49 PM 8/12/2006, you wrote:
sense that one may take the option to split a database across
multiple physical files). Its internal structure is nothing like,
say, the internal structure of an Access database, which is merely a
specialised folder containing a multiplicity of other files in a
structure managed by the Access engine.
just a Firebird database that is owned by the server. Its location
in the root directory is a deliberate requirement; but it's not a
different kind of database. When the engine needs to connect to the
security database, it has a hard-coded requirement to find it in the
RootDirectory. Even that is going to change in Firebird 3, with the
advent of plug-in access module capability.
is located outside the RootDirectory (nor even inside it!). It
needs only to know where to find the database file in the host's
physical storage structure when it receives a connection request. It
can (and should be encouraged to) accept an alias for a filesystem path.
Indeed, a database doesn't even have to be in the system's file
structure at all...it is possible (although not demonstrably
beneficial) to maintain a Firebird database on a raw device.
Furthermore, you shouldn't put databases that are for development or
production use in the RootDirectory. You should put them somewhere
"appropriate", where you can precisely control access privileges,
e.g. in a sandbox area for development and testing and in a
production area for production use. A "production area" would
typically be a fast disk or disk array with no competition for i/o or
other resources such as swap memory.
Since you asked so nicely... ;-)
./heLen
> > >I would prefer a direct Firebird command (if there is any) or theExactly. A database lives in one logical file ("logical", in the
> > >name and fields of a metadaba table (I could not find it anywhere)
> > >or a function that returns the paths of the databases that are served.
> >
> > There is no such thing, and the server has no way to detect whether a
> > file is a database or not, except by attempting to process a client
> > request to connect to a specified file. Even the Services API wraps
> > client requests. The server doesn't have some kind of routine that
> > runs around the filesystem asking files whether they are databases....
>
>Oh, so that means that there is no directory structure to a firebird
>database
sense that one may take the option to split a database across
multiple physical files). Its internal structure is nothing like,
say, the internal structure of an Access database, which is merely a
specialised folder containing a multiplicity of other files in a
structure managed by the Access engine.
>save for the security database of the firebird home directory?The security database isn't a "directory structure", either. It is
just a Firebird database that is owned by the server. Its location
in the root directory is a deliberate requirement; but it's not a
different kind of database. When the engine needs to connect to the
security database, it has a hard-coded requirement to find it in the
RootDirectory. Even that is going to change in Firebird 3, with the
advent of plug-in access module capability.
>How do you inform the server of a firebird database that is locatedThe server doesn't need to, or want to, be informed that a database
>outside the RootDirectory?
is located outside the RootDirectory (nor even inside it!). It
needs only to know where to find the database file in the host's
physical storage structure when it receives a connection request. It
can (and should be encouraged to) accept an alias for a filesystem path.
Indeed, a database doesn't even have to be in the system's file
structure at all...it is possible (although not demonstrably
beneficial) to maintain a Firebird database on a raw device.
Furthermore, you shouldn't put databases that are for development or
production use in the RootDirectory. You should put them somewhere
"appropriate", where you can precisely control access privileges,
e.g. in a sandbox area for development and testing and in a
production area for production use. A "production area" would
typically be a fast disk or disk array with no competition for i/o or
other resources such as swap memory.
Since you asked so nicely... ;-)
./heLen