Subject | Re: [IBO] Getting Remote Computer Name |
---|---|
Author | Helen Borrie |
Post date | 2006-02-25T00:16:34Z |
At 01:48 AM 25/02/2006, you wrote:
installer scripts using products like InstallShield or Inno, those
companies also run forums.
Some comments on assumptions:
the server because the Firebird API requires it. You simply can't
use maps or shares for connecting to databases.
When you were using the BDE, you also used the absolute path. You
configured it in your BDE setup with an alias and your VCL TDatabase
referred to the alias. In your BDE setup, your alias included the
Server name.
In IBO, Server and Path are separate and you assign a Protocol. IBO
constructs it own connection string from these elements. If it
resolves to something "illegal", the API will try to use it and
return an exception.
Consider the elements:
Path: c:\mydata\mydb.fdb (this is the absolute path to the database,
as seen by the server)
Server: MyWinServer (this is the network node name of the host
machine, where the Firebird server is running)
or
198.12.13.1 (The static IP address of the host node, IF the Protocol is TCP/IP)
Protocol: options available for Firebird are cpTCP_IP, cpNETBEUI and
cpLOCAL. cpLocal refers to the IPServer that is available only to
Superserver (including the Embedded Server). Except for embedded,
cpLocal should not be used for production.
Now, let's look at the connections strings that IBO will build:
-- if the Protocol is cpLocal, the entire string will be
c:\mydata\mydb.fdb. The server, database and application must all be
on the same machine, or you will get an exception
-- if the Protocol is cpTCP_IP, the entire string will be
MyWinServer:c:\mydata\mydb.fdb
or
198.12.13.1:c:\mydata\mydb.fdb
depending on the Server entry
-- if the Protocol is cpNETBEUI, the entire string will be
\\MyWinServer\c:\mydata\mydb.fdb
In the case of NetBeui, it might look a bit like an UNC path but
notice that the absolute disk (i.e. partition) identifier is (and
must be) in the path.
In all cases, if you use Firebird's path aliasing, it will be
transparent to IBO. By this, I mean that IBO will use it's rules for
constructing the connection string and will pass the alias to the API
in the connection request. The actual resolution of the path occurs
on the "other side" of the API, where the Fb client library
interfaces with the server (this is a subsystem known as "the Y-valve").
For security reasons, as well as site flexibility, you shouldn't be
hard-coding either the hostname or the path in your app.
For the path, it is a very, very good idea to use Firebird's aliases
in your apps, in preference to the actual path. Suppose
firebird.conf on your development machine defines this alias:
MyAlias = c:\mydata\mydb.fdb
On the deployment site, the host server reserves the C-drive for
software only, and keeps databases on drive D. Then, firebird's
aliases.conf's entry there would be
MyAlias = d:\data\MyApp\mydb.fdb
Or, if the site you are deploying to runs Firebird on a Linux host,
the aliases.conf entry might be:
MyAlias = /data/myapp/mydb.fdb
Thus, there is nothing to change when you deploy your app. Your app
simply doesn't know or care.
to be. This applies to BOTH the host machine and the
aliases.conf. So your installer needs to be able to find the
hostname of the *DATABASE* server (which is not necessarily going to
be the same as the hostname of the software installation server).
installer needs to SET the server and database path, not GET
them. If the installer is a Delphi app, you would supply an ini
file. How you use it depends on how you want to do this deployment.
At the end of the day, you want to be able to
--- record/read/create the file path[s] to the database[s] and
shadow[s] (if you are shadowing)
--- create [an] alias[es] in the aliases.conf file of the DATABASE
host for this [these] paths
--- record the node name of the DATABASE host
The usual way with Delphi is to use an ini file. Whether you read
from or write to the ini file (or a mixture) depends on how you're
controlling things, e.g. insisting on hard paths for everything (not
advisable, but you can force this by hard-coding the ini file) or
allowing the Responsible Adult running the installer to input some things.
There may be other things you need to make your installer do, such as
checking the %sysdir%\drivers\etc\HOSTS file for a DNS entry for the
database host, et al. Write a Delphi routine to convert the ini file
entries into Registry entries on the client (and possibly make this
routine available to be re-run in future when the hostname and/or
database path change, e.g. when moving the database server from a
Windows to a Linux host).
Installer tools have similar capabilities.
Delphi/Firebird environment issue. There again, Delphi-specific
questions aren't too welcome on the firebird-support list (the place
you go for Firebird-specific questions). It happens to be a Saturday
morning here, so I answered this with more off-topic detail than
would be acceptable normally. This is an overt abuse of power, since
I'm the moderator of this list. :-)
Helen
>IS IT OK to ask "off topic" questions here?As a rule, no. This list is specifically about IB Objects.
>This is a general Delphi question.Borland has forums for general Delphi questions. If you're writing
installer scripts using products like InstallShield or Inno, those
companies also run forums.
Some comments on assumptions:
>I have a two part installer for my program. The main installer is designedActually, this assumption is wrong. IBO wants the absolute path on
>to run on the server and it sets up Firebird and then the database. It then
>installs the client installer on the server.
>
>So the client installer should be run on each client machine directly off of
>the server. By so doing I want to get the server name to set up the client
>so it can find the database.
>
>My initial version of this just got the path information (the BDE just
>wanted the relative path to the database) but of course IBObjects wants the
>absolute path on the server.
the server because the Firebird API requires it. You simply can't
use maps or shares for connecting to databases.
When you were using the BDE, you also used the absolute path. You
configured it in your BDE setup with an alias and your VCL TDatabase
referred to the alias. In your BDE setup, your alias included the
Server name.
In IBO, Server and Path are separate and you assign a Protocol. IBO
constructs it own connection string from these elements. If it
resolves to something "illegal", the API will try to use it and
return an exception.
Consider the elements:
Path: c:\mydata\mydb.fdb (this is the absolute path to the database,
as seen by the server)
Server: MyWinServer (this is the network node name of the host
machine, where the Firebird server is running)
or
198.12.13.1 (The static IP address of the host node, IF the Protocol is TCP/IP)
Protocol: options available for Firebird are cpTCP_IP, cpNETBEUI and
cpLOCAL. cpLocal refers to the IPServer that is available only to
Superserver (including the Embedded Server). Except for embedded,
cpLocal should not be used for production.
Now, let's look at the connections strings that IBO will build:
-- if the Protocol is cpLocal, the entire string will be
c:\mydata\mydb.fdb. The server, database and application must all be
on the same machine, or you will get an exception
-- if the Protocol is cpTCP_IP, the entire string will be
MyWinServer:c:\mydata\mydb.fdb
or
198.12.13.1:c:\mydata\mydb.fdb
depending on the Server entry
-- if the Protocol is cpNETBEUI, the entire string will be
\\MyWinServer\c:\mydata\mydb.fdb
In the case of NetBeui, it might look a bit like an UNC path but
notice that the absolute disk (i.e. partition) identifier is (and
must be) in the path.
In all cases, if you use Firebird's path aliasing, it will be
transparent to IBO. By this, I mean that IBO will use it's rules for
constructing the connection string and will pass the alias to the API
in the connection request. The actual resolution of the path occurs
on the "other side" of the API, where the Fb client library
interfaces with the server (this is a subsystem known as "the Y-valve").
For security reasons, as well as site flexibility, you shouldn't be
hard-coding either the hostname or the path in your app.
For the path, it is a very, very good idea to use Firebird's aliases
in your apps, in preference to the actual path. Suppose
firebird.conf on your development machine defines this alias:
MyAlias = c:\mydata\mydb.fdb
On the deployment site, the host server reserves the C-drive for
software only, and keeps databases on drive D. Then, firebird's
aliases.conf's entry there would be
MyAlias = d:\data\MyApp\mydb.fdb
Or, if the site you are deploying to runs Firebird on a Linux host,
the aliases.conf entry might be:
MyAlias = /data/myapp/mydb.fdb
Thus, there is nothing to change when you deploy your app. Your app
simply doesn't know or care.
> If the user uses a UNC path to run theYour installer needs to know where the user site wants the database
>installer I can get the machine name, but if they use a mapped drive I won't
>have the machine name in the path.
to be. This applies to BOTH the host machine and the
aliases.conf. So your installer needs to be able to find the
hostname of the *DATABASE* server (which is not necessarily going to
be the same as the hostname of the software installation server).
>How can I determine the machine name for a mapped drive (or even if it's aThe question is irrelevant. For each specific deployment, your
>UNC path, perhaps without parsing the name out of the path information)?
installer needs to SET the server and database path, not GET
them. If the installer is a Delphi app, you would supply an ini
file. How you use it depends on how you want to do this deployment.
At the end of the day, you want to be able to
--- record/read/create the file path[s] to the database[s] and
shadow[s] (if you are shadowing)
--- create [an] alias[es] in the aliases.conf file of the DATABASE
host for this [these] paths
--- record the node name of the DATABASE host
The usual way with Delphi is to use an ini file. Whether you read
from or write to the ini file (or a mixture) depends on how you're
controlling things, e.g. insisting on hard paths for everything (not
advisable, but you can force this by hard-coding the ini file) or
allowing the Responsible Adult running the installer to input some things.
There may be other things you need to make your installer do, such as
checking the %sysdir%\drivers\etc\HOSTS file for a DNS entry for the
database host, et al. Write a Delphi routine to convert the ini file
entries into Registry entries on the client (and possibly make this
routine available to be re-run in future when the hostname and/or
database path change, e.g. when moving the database server from a
Windows to a Linux host).
Installer tools have similar capabilities.
>Let me know if this is not an acceptable question to ask here.It's not, really, since it's not IBO-specific but a general
Delphi/Firebird environment issue. There again, Delphi-specific
questions aren't too welcome on the firebird-support list (the place
you go for Firebird-specific questions). It happens to be a Saturday
morning here, so I answered this with more off-topic detail than
would be acceptable normally. This is an overt abuse of power, since
I'm the moderator of this list. :-)
Helen