Subject | RE: [ib-support] All about different connection strings? An update |
---|---|
Author | Helen Borrie |
Post date | 2002-11-06T08:11:34Z |
At 02:32 AM 06-11-02 -0500, you wrote:
application can see the file but the db client can't see the server, then
the client isn't resolving that IP address to a local location.
You mentioned this:
\\aldis-server\apps\mydatabase.gdb - This not a valid TCP/IP addressing path.
loopback. "Local" means "local to this machine" not "local on some other
machine".
1. That you need to have your server name resolve to a real IP address,
i.e. one that is visible to the whole network...that is, the server must
announce itself with that IP address and the remote clients must recognise
it (preferably through a HOSTS file entry). (localhost or 127.0.0.1 is not
a valid address for a remote client to connect to. It is valid *only* if
the client is on the same physical box as the server.)
2. That UNC notation and/or NetBEUI server notation and/or network shares
are not valid in TCP/IP connection paths
These are "safe" mistakes if you get them wrong - you just won't be able to
connect.
The "unsafe" one is having two different users (local or remote) connect
(successfully), one with each of these path variants included in the
connection string (any connection format):
c:mypath\mydb.gdb
and
c:\mypath\mydb.gdb
With Firebird RC2 or higher, a connection attempt using one version of the
path will fail if any connections already exist that were made with the
other format.
With InterBase, you will get the connection string bug - and corruption.
>HiThat is Windows local connect.
>Further to the details on connection strings, I can complicate the issue by
>adding the following list of errors when connecting via various options.
>This applies to W2K servers, NT4 servers, W2K and Win98 workstations.
>IP only, DHCP for address on clients, Novell Client for Windows, Client for
>Microsoft Windows
>Firebird 1.0 on server and Firebird Client on workstations
>Server address is 192.168.0.15, client addresses 192.168.0.40 on
>192.168.0.15 and aldis-server is set in HOSTS (correct settings)
>192.168.0.15 and aldis-server is set in LMHOSTS (correct settings)
>
>Data Source is shown in a listbox for user feedback
>C:\APPS\MYDATABASE.GDB always shows on server regardless of settings
>\\aldis-server\apps\mydatabase.gdb always shows on client
>
>When Data Source is:
>1
>C:\APPS\MYDATABASE.GDB works ok on local/server and client machines
>2The IP address doesn't resolve correctly from the remote client. If the
>192.168.0.15:C:\APPS\MYDATABASE.GDB works ok on local/server machine
>error on client machine
>Dynamic SQL Error -901 feature is not supported. Program loads ok but no
>database available, so the client is locating the correct folder
application can see the file but the db client can't see the server, then
the client isn't resolving that IP address to a local location.
You mentioned this:
\\aldis-server\apps\mydatabase.gdb - This not a valid TCP/IP addressing path.
>3As expected. 127.0.0.1 is reserved as the address for TCP/IP local
>127.0.0.1:C:\APPS\MYDATABASE.GDB works ok on local/server machine
>error on client machine
>Unable to complete a network connection to host "127.0.0.1"
>Failed to establish a connection
>unknown win32 error 10061
loopback. "Local" means "local to this machine" not "local on some other
machine".
>4Again, reserved for 127.0.0.1, local loopback, as above.
>localhost:C:\APPS\MYDATABASE.GDB works ok on local/server machine
>error on client machine
>Unable to complete a network connection to host "localhost"
>Failed to establish a connection
>unknown win32 error 10061
>Sorry to spoil the party - but this is the direct opposite of a recentYou won't have a problem if you get two things straight:
>email from Alan - another one, not me.
>It would be good to resolve this because I know I will have a problem soon
>with different IP addresses on a WAN - it must affect a lot of potential
>users
1. That you need to have your server name resolve to a real IP address,
i.e. one that is visible to the whole network...that is, the server must
announce itself with that IP address and the remote clients must recognise
it (preferably through a HOSTS file entry). (localhost or 127.0.0.1 is not
a valid address for a remote client to connect to. It is valid *only* if
the client is on the same physical box as the server.)
2. That UNC notation and/or NetBEUI server notation and/or network shares
are not valid in TCP/IP connection paths
These are "safe" mistakes if you get them wrong - you just won't be able to
connect.
The "unsafe" one is having two different users (local or remote) connect
(successfully), one with each of these path variants included in the
connection string (any connection format):
c:mypath\mydb.gdb
and
c:\mypath\mydb.gdb
With Firebird RC2 or higher, a connection attempt using one version of the
path will fail if any connections already exist that were made with the
other format.
With InterBase, you will get the connection string bug - and corruption.