At 10:00 PM 1/04/2004 +0000, you wrote:

>But then I saw this message thread, indicating that having two
>programs accessing the same server/database on the same machine could
>cause problems.

For the record, the connection string bug was never manifested by having a
simultaneous local connection and a network connection with identical
strings for the path element. It affects InterBase only, and only when two
concurrent connections exist with both Windows-accepted path syntaxes - any
mix of local and remote. It's the path element that causes that bug. The
solution to use the network path for local connections is an illogical
overkill that's costing you response-time.

>Getting to the point (sorry for this long message), I'm not sure now
>whether this experiment is a good idea. I need to know:
>
>1) What is likely to happen if we have two programs on the same
>machine as the server that connect with just the (identical) path
>name, with no machine name? Does this cause database corruption? If
>not, what symptoms would we expect to see? (I'm wondering if this
>contributes to some of the database crashes.)

Not corruption, that I'm aware of, just crashes from memory conflicts. Of
course, crashes will cause corruption if you have forced writes off.

>2) Is it possible that introducing the server name (instead of the
>127.0.0.1 stuff or "localhost") could be causing database connection
>network traffic even though it's on the same computer?

Yes. If you use the network node name for a local connect, then the
traffic goes via the network, not local loopback. You *have* to do this
with transaction servers in the (undesirable) situation where the database
server and the transaction server are on the same machine. Use local
loopback to connect your application server to the database if you have no
reason to use the network.

If you use both named pipes and tcp/ip on the same wire, you will augment
traffic-related delays. Windows-lovers will tell you it can't happen that
named-pipes overloads will crash the network server but it's a myth. It
does happen when you're serving both the network and the database for a
busy site off a single host machine. I've seen this as a showstopper
problem on both hybrid networks (Firebird running on Windows with tcp/ip
clients in competition with named pipes File and Printer Sharing) and named
pipes-only networks (Firebird or MSSQLServer on the named pipes host with
uncontrolled access by clients to named pipes-networked services).

>And if so, could WAN originated network problems be causing problems
>shutting down the server program at night?

How long is a piece of string? What kind of "problems" are you talking
about? Network backups happening in the named pipes layer at the same time
as your application server is trying to commit a day's-worth of
commit-retaining work via the network?

Now, a really cool way to corrupt a database is to include your database
directory in the hit list of Windows backup (or any filesystem archiving
tool, including WinZip, SystemRestore, yada yada) and have it perform
backups while you have a database that is not in shutdown state....

/hb