At 09:32 AM 21/10/2004 +1000, you wrote:

>We had some issues helping a customer upgrade their version of our
>Delphi/Firebird application yesterday.
>
>They had copied the server configuration of our system (reports, .gdb etc)
>to a new drive and intended to use the new drive from then on. They had
>pointed their workstations via explorer at the new drive. They changed their
>backups to be the new drive rather than old.
>
>They hadn't however altered other settings specific to our software and the
>users running our app. were still affecting the original DB.
>
>Anyway to cut a long story short things were confused but supposedly all
>sorted in the end with some file copying (eg: the .gdb) having being done.
>
>Shortly after however the users have recommenced using the system and have
>quickly reported in an "urgent" email the following error we've not seen
>before:
>
>"ISC ERROR CODE:335544351
>
>ISC ERROR MESSAGE:
>UNSUCCESSFUL METADATA UPDATE
>LOCK TIME-OUT ON WAIT TRANSACTION
>OBJECT D:SHARED\LANDPA~1.GDB IS IN USE"
>
>The object of course is the database file.

Aaah! This is Firebird Superserver protecting itself from naughty
connection strings - the famous "Connection Path Bug". You can read about
the details in the Firebird 1.0 release notes. In short, in InterBase, if
two applications connect to the same database with different
(Windows-permitted) connection path formats, between them these
applications will corrupt the database in very horrible ways.

This was one of the first IB bugs that Firebird ever fixed. The first
connection to the database causes the database file to be opened with an
exclusive lock. Along comes someone else with a naughty path like your
example, and they get locked out.

The rules at play here are:

-- All apps must connect to an absolute path as seen by the host
machine. So, if the DB is on drive D in a folder named databases, all apps
must use exactly this pathname (no shares, no mapped drives):

D:\databases\OurDB.fdb
(Notice the backslash between the drive designator's colon and the first
dir in the pathname!!!)

So, remote clients connect with \\HostServerRealName\D:\databases\OurDB.fdb
using Windows named pipes (sometimes referred to as NetBEUI) and with
HostServerRealName:D:\databases\OurDB.fdb using TCP/IP.

-- All other apps must then connect using the exact same pathname.

It's "sort-of OK" to omit the server name if the client is connecting
locally to run a command-line tool, for example. (This uses the
notoriously flaky IPServer protocol).

Otherwise, it's highly recommended to use TCP/IP local loopback for local
connections (localhost, IP address 127.0.0.1, available only to a local
client).

Using TCP/IP, If the same server goes by different HARD TCP/IP host names
(not talking about UNC aliases here), then there's no problem with
different clients using different host names. E.g., on my network, my
Windows server is in the HOSTS file as all of these:

10.23.24.1 dev
10.23.24.1 hotchicken
and, also, of course, I have
127.0.0.1 localhost

Any of these host names works fine, e.g. I can be logged in locally to
localhost:D:\databases\OurDB.fdb with one app and also to
dev:D:\databases\OurDB.fdb. Meanwhile, another app somewhere can log in to
hotchicken:D:\databases\OurDB.fdb.

./heLen