Subject | Re: [Firebird-Architect] Database Capabilities |
---|---|
Author | Jim Starkey |
Post date | 2005-07-22T14:33:10Z |
Claudio Valderrama C. wrote:
We currently don't have a mechanism to address a server, per se, only
databases. In Vulcan, and to a lessor degree in Firebird, the database
name can be remapped on the client, intentionally obscuring the server
name. Since there is no way to resolving the mapping other than to
attach a database, even decomposing the database name is, in the general
case, impossible.
Further, the remote server (actually the Y-valve on the remote server)
doesn't have any information about "newness" of provides. The Y-valve
does get a list of provider names from the corresponding database object
in the configuration files, but the provider list may include both 32
and 64 bit providers, half of which won't be loadable), services
providers, remote interfaces, gateways, and who know what else over time.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>Otherwise, we should consider a special call that can return theFirst, why do you want this information? Second, what would you do with it?
>capabilities of the newest provider the y-valve can find, requesting that
>such provider handles databases directly instead of being a gateway to
>something else.
>
>Does this make sense to you?
>
>
>
We currently don't have a mechanism to address a server, per se, only
databases. In Vulcan, and to a lessor degree in Firebird, the database
name can be remapped on the client, intentionally obscuring the server
name. Since there is no way to resolving the mapping other than to
attach a database, even decomposing the database name is, in the general
case, impossible.
Further, the remote server (actually the Y-valve on the remote server)
doesn't have any information about "newness" of provides. The Y-valve
does get a list of provider names from the corresponding database object
in the configuration files, but the provider list may include both 32
and 64 bit providers, half of which won't be loadable), services
providers, remote interfaces, gateways, and who know what else over time.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376