Ok, an update...

> The problem here is that you are using a very old version of Firebird,
> which had not yet fixed the connection path bug. From your description,
> your TCP/IP might well be using the "bad" syntax that causes this problem
> to surface: since you said the remote client was "accessing it by the same
> path, but preceeded (sic) by the server's IP address and a colon". So here
> is what you possibly have:
> User A (local): c:\databases\MyDb.gdb
> User B (remote): 999.999.999.999:c:databases\MyDb.gdb
>
> or this variant:
> User A (local): c:databases\MyDb.gdb
> User B (remote): 999.999.999.999:c:\databases\MyDb.gdb

I checked with the user today, and this is definitely not the problem. I had
them carefully read me both of the connection paths, character by character.
Both were EXACTLY the same, both specified by IP address, and no missing colons
or backslashes. They were exactly the same, down to the character. The only
possible difference that I didn't account for is capitalization, but I'm going
on the assumption that case is not an issue.

> In this scenario, don't overlook the possibility that someone was
> simultaneously accessing the database using another client (e.g. IBConsole)
> and causing the same problem outside the control of your application.
> I would want to examine the BDE path setup for EVERY user who has ANY sort
> of access to this database, including the boss, if you gave him a DB access
> tool, and anyone else who can connect to the database outside the control
> of your application.

No, this is a two-machine network, just these two computers, and nobody was
using IBConsole or anything other than my application.

> Now, if you can eliminate that one, move on to the next possibility: that
> c:databases\MyDb.gdb is pointing to a network share and/or a mapped
> drive. Is this possible?

No. The path on both machies is:

192.168.0.1:C:\Program Files\TRS5\data\data300.gdb

> Another possibility is an architectural bug that you can inadvertently
> create yourself. In a BDE app connecting to a database, you should use a
> TDatabase for the database connection and point its DatabaseName and Alias
> properties to a BDE alias, e.g. Then, for all datasets (TTables in your
> case) should pick up their DatabaseName property from the TDatabase
> (selected in the IDE's property editor, not typed in). This ensures that
> all datasets are involved in a single connection and transaction context.
> However, Delphi will allow you to type a path name directly into the
> DatabaseName property of your TTables. In this case, the TTable will make
> its own connection (DatabaseName + TableName) and not operate through the
> connection/transaction context that is being used by the rest of the
> application.

I doubted this, but checked anyway. It is not the case. All TTables go
through my TDatabase object.

> fwiw, Firebird 1 won't let you have a local connection and a TCP/IP
> connection simultaneously. If you have a client which acesses the server
> locally in a TCP/IP network, you *must* use a local loopback connection. A
> Windows local connection has to have exclusive access.

Thanks for the heads up. This will break most of my clients' installations
when they upgrade to 1.0. Ugh.

> There is another dimension that hasn't been mentioned so far: the BDE
> version. The InterBase driver in Delphi 4 and 5 supports InterBase
> 5.x. The one that shipped with Delphi 4 had known bugs. The one with D5
> had known bugs. Neither was ever certified for use with ODS-10 databases
> (IB 6.x, Firebird...) Even the BDE 5.2 IB 6.x driver that shipped with
> Delphi 6 has known bugs (different ones!)

The BDE version is 4.0, which shipped with BCB4. Is this a problem?

> I don't think it is very sensible of you to have deployed an early beta of
> Firebird into production. You should upgrade your customers to Firebird
> 1.0 without delay, to avoid a large number of known bugs in that old
> beta. The obvious architectural flaws (BDE and TTables) you plan to
> address...but there is a good chance that your immediate problem will show
> up as an exception with Firebird 1.0.
>

Well, here's the thing with that. When Interbase 6 went out of beta, I
modified the next release of my app to work with it. I made deals and took
orders, based on the fact that Interbase 6 was free. Everything was going
perfect in my development and testing. Just before shipping, I read that FB
0.9.4 was available, and that it had fixed some bugs that were present in IB6.
It seemed like a better choice to deploy the beta FB than the less-stable
non-beta IB6. I don't think that that was the wrong choice. Besides, the
IBPhoenix web site touts FB 0.9.4 as "A build that has been successfully run
through the complete TCS test suite and has proved to be stable in operational
environments.".

-Joe