At 06:40 AM 4/03/2003 +0200, you wrote:

>Good day
>\-\=-\=-=\-\=-
>
>I have sat down and looked at the source of the Delphi program that works
>with the database as the idea that the trigger on the database is giving a
>problem does not
>make sense and this is the result.
>
>I have a Delphi server program and a Delphi client program that runs on the
>same database. Client is Delphi 3 and Server is Delphi 5.
>The client program starts a business trigger and the server then tries to
>act on this trigger, but its connection that is setup in the BDE as
>localhost:d:\db\promed.gdb is then dropped. in the sense that I get a 10054
>error locally at the server. It seems this is happening at a other client also
>but from the client machines also. Will the server program really have a
>problem if there is a problem with the networkcard as locahost is the
>loopback device that
>is 127.0.0.1 ???

No, this is just fine for the server program - just as the doctor ordered.

>Interbase version : 5.6
>Database sizes from : 250 - 830 MB
>
>Other strange events :
>
>When trying to get the connection user list of the interbase database I get
>a connection lost to database. After that the server crashes and need to be
>restarted.
>
>PS : Has anybody noticed that if the alias via BDE to the interbase
>database is <servername>:d\db\promed.gdb (Notice there is no : after the
>first d) and there is a network share for D.

This is simply wrong. There are two known problems here.

First, Windows will allow this bizarre connection string and, at the time
IB 5.6 was distributed, Borland didn't know about it. This situation will
cause overt and irreparable data corruption because, effectively, the
database server treats the two different styles as connections to two
*different* database - hence, no concurrency protection, since each
connection appears as an exclusive connection. The more users that log in,
the worse the damage will get. I'd say you have to be GRATEFUL that the
server crashes.

The second thing (and I know that I have mentioned it at least once in this
thread) is that a remote client can't connect to a share (even if you get
the protocol right, which it isn't).
Period.

>Then SOMETIMES on some
>networks there is a problem that if this method of connection WORKS then
>the datbase gets corrupt FAR bejond repair. I get the Idea that it uses
>network cache or something and is out of sync with the machines OS cache.

It's not odd at all. It is just a case in point of a known bug. It is
known as "the connection path bug". Make sure you fix it PDQ.

Boy, hasn't it taken some squeezing to get at the real parameters of this
problem...?

heLen