| Subject | Re: [IB-Architect] Forcing Interbase on Windows to use TCP/IP |
|---|---|
| Author | Helen Borrie |
| Post date | 2000-11-30T14:22:37Z |
At 10:53 AM 30-11-00 +0000, you wrote:
Servername:D:\path\path\databasename - both colons and all slashes must be
there. It's supposed to work with either back or forward slashes but I've
proven that forward slashes don't work on my setup.
and this is Linux notation for TCP/IP
Servername:/path/path/databasename (no drives on *IX)
\\Servername\D:\path\path\databasename
database outside of application control, you will be privy to the physical
path to the database. You only need to KNOW it, you don''t need to see it.
reason above. If your security status prevents you from knowing the
connection path, it sure as heck shouldn't be letting you search for it as
a willy-nilly interactive user.
There's been some quite lively discussion here about an aliasing system for
pointing to the database path, to enable you to create self-installing
deployments, perhaps even storing this stuff in its own database. I think
it's a fair summary to say that most people think the handling of
connection strings needs improvement. You might be interested in browsing
the archives going back about three months
(http://www.egroups.com/messages/ib-architect).
Cheers,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
> >From what I can glean from the documentation and experimentation, theNo, you will come to grief with this. The TCP/IP format for windows is
>only way you can ensure that Interbase uses TCP/IP to connect to
>remote databases is to use the format:
>
>machinename:/drive-letter/databasename
Servername:D:\path\path\databasename - both colons and all slashes must be
there. It's supposed to work with either back or forward slashes but I've
proven that forward slashes don't work on my setup.
and this is Linux notation for TCP/IP
Servername:/path/path/databasename (no drives on *IX)
>in the connect string. If you don't it seems to use NetBEUI, which isUNC notation gets you NetBeui
>very slow.
\\Servername\D:\path\path\databasename
>The problem with this comes when you try to open databasesBut one assumes anyway that, if you have the right to connect to the
>which are on a remote server. You can see the files from your local
>machine and you have the UNC name. However, it's not possible to get
>the full local pathname on the server remotely unless you have admin
>rights on that server because of the NT security model.
database outside of application control, you will be privy to the physical
path to the database. You only need to KNOW it, you don''t need to see it.
>This is a nuisance and means that you have to start thinking aboutInterBase doesn't do it. Personally, I can't see why it should, for the
>installing extra services on the server just to do the name
>translation. Interbase is already running there, so it couldn't it do
>it? Or is it already possible?
reason above. If your security status prevents you from knowing the
connection path, it sure as heck shouldn't be letting you search for it as
a willy-nilly interactive user.
There's been some quite lively discussion here about an aliasing system for
pointing to the database path, to enable you to create self-installing
deployments, perhaps even storing this stuff in its own database. I think
it's a fair summary to say that most people think the handling of
connection strings needs improvement. You might be interested in browsing
the archives going back about three months
(http://www.egroups.com/messages/ib-architect).
Cheers,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________