At 11:54 PM 30/01/2006, you wrote:

>Finally isn't so easy. I get almost the same behavior but not so often.
>
>The error message is: 'error reading data from the connection'
>
>this was a known bug in 1.5.2 but I get it even in 1.5.3.

Hmm, hardly. A network error is not a Firebird bug. It might be
indicative of something buggish in the network interface but it only
indicates is that the network connection between the server and a
client has been lost. You will see it, for example, when Joe User
uses the OFF switch to end his database session. The server is
merely reporting "I had a connection to a client but now it's gone".

>The 1.5.2 version the log has the follow error appeared many times:
>DENNISF (Client) Thu Jan 26 13:16:10 2006
> INET/inet_error: send errno = 10054
>The 1.5.3 version doesn't shows anything about this.

What would you expect it to show? The server has no way to know WHY
a client disappeared.

>This issue is extremely similar (but with interbase) with this one
>referenced to the follow link
>http://www.experts-exchange.com/Databases/Interbase/Q_21561378.html
>but I have no access.
>
>Any suggestions???

You can scroll down for the responses...but there's nothing there of
much calorific value.

Find out what's happening on the network, with both man and
machine. The most usual thing will be users crashing out. If they
are not willing to behave properly, then you'll just keep getting
10054 errors from the network. It doesn't hurt anything and,
eventually, the server will abandon the dead connection and clean up
anything it has left around.

If the server itself isn't crashing, and the users are well-behaved,
then look for the cause of the problem in your network configuration
(apparently idle IP addresses being hijacked by DHCP?) or faulty
hardware/cabling.

Originally, you said:

> This is happening also if the connection is remote and sql server is on
> the same machine with the application (the ip address of the connection
> is this one of the pc), so the problem is not on the network layer,
> probably it is a bug with the tcp ip connection. Local connection has no
> problem at all.

Do you understand that the "tcp ip connection" *IS* the network
layer? Local connection doesn't use TCP/IP - communication between
server and client occurs in an emulated network layer (ipserver) in
shared inter-process communication space. It's not affected by a
faulty network because it doesn't use the network.

Have you checked whether you have the wrong client library installed
on the problem clients? I mean, checking the property sheet of
gds32.dll on each node and verifying that the build number is the
same as the build number of the server...?

./hb