My apologies if this shows up twice. I think I did something wrong
the first time, but maybe it can delay more than a half hour?
Anyway...

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

"You can run many different apps that connect to the same database.
But to use local connect is not a safe way to do so."

In that same thread ("TCP/IP Necessary?"), you also wrote:

"It [Windows local protocol] uses an internal engine called IPServer,
for a single local connection. The client and the server share the
same piece of inter-process communication (IPC) memory to emulate a
network connection. Multiple connections can be dicey."

Nando Dessena then wrote:

"Hearsay suggests it's not safe practice, but I've been doing in the
past with early versions of IB and never had a problem due to that. I
have abandoned named pipes before the appearance of Firebird, though,
so I cannot speak for the present. The XNET protocol implementation,
which is bound to transparently replace named pipes in FB2, should
clear all current problems, as the developers say."


We have been using Interbase 5.6 with our Point of Sale product since
5.6 was released. (We started on 4.0.) Until the most recent
version, we generally had our Transaction Manager (middle tier) AND
our Replacation Agent running on the same machine as IB, using local
protocol to connect to the database. Our reporting and configuration
program, which connects to the DB in a traditional 2 tier
architecture, runs on separate machines and uses TCP/IP or NetBEUI
protocols.

In the most recent version, we added code to force EVERY database
connection string to include the server name, "just in case" the
known issue with two different database paths causing the server to
think it was working with two different database files could
be "fooled" by having the TM use "c:\db\sitename.gdb" while the
clients use "server:c:\db\sitename.gdb". We had been told that the
pathname problem could ONLY be caused by the actual path part (from
the "c" onward), but we did this "just in case".

The change was made because we've been having sporadic database
corruption problems (and with 300+ installed sites, "sporadic" can
mean once a week for us even if it means once every 6 years to any
specific site.)

We don't have enough data yet to know whether or not this reduced
corruption problems (we've gotten some cases at sites running this
version, but it's hard to tell if it's less frequent than at older
version sites.) But what we HAVE gotten is two chains running their
multiple sites on wide area networks, that seem to have much MORE
problems, that we think MAY be related to putting the server name in
the path string, causing the connections between the transaction
manager and server to be succeptible to network problems.

To see if the protocol was indeed the problem, we were about to issue
a patch release to those customers that removes the code that forces
the server name into the database connection string. We're also
interested in switching back to local protocol because it appears to
be somewhat faster- about 1/3 faster in FB 1.5, which our latest
version is switching to.

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

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.)

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? And if so,
could WAN originated network problems be causing problems shutting
down the server program at night?

Again, sorry for all the detail, but I'd rather provide too much than
not enough. I really appreciate any help anyone can provide with this.