At 09:41 AM 18/09/2009, you wrote:

>Hello:
>
>I have an application installed in a network with the following technical data:
>
>Delphi 5 with IBX
>FireBird 2.1.2.18118 SS
>Server: Windows 2003 Server
>Clients: Windows XP SP3
>
>Using the application in the server or connecting to the server via Terminal server, everything works perfect.
>
>Using the application in any of the client PCs of the local network, ALMOST everything works perfect. In only 3 of the tables, when the application executes a SELECT * FROM <TableName>, the application "hangs". In firebird.log I see the following:
>
>INET/inet_error: read errno = 10054

It means the TCP/IP socket has gone - "connection reset by peer" - if it is the application that "hangs" (rather than the server that crashes) then look at the user's environment to find out why these sets cause the application to blow up.

-- one possible cause could be that the TCP/IP transport has been configured too aggressively for timeout. Check that with the network admin.

-- Maybe the application depends on some kind of local cache (like a BDE application, for example) and either no disk space is available or the size of the set is too large to be cached.

>It is very strange that the problem is only with 3 of the tables of the database. And they are not the biggest or the smallest or the ones with more fields.

>I chose one of the tables with thie problem, and I made the following trying to make a SELECT * FROM <TableName>. The table has 96 fields and 253 registers.

"More fields" might be less of an issue than the SIZE of each record. 96 integer fields are exponentially smaller than 96 char(32767)!! ;-) It's conceivable that the TCP/IP timeout is too brief to allow for the waiting time involved to fill up a huge buffer.

>To access the database I was using TCPIP style. For example: SERVER:ALIASOFMYDATABASE. Following a suggestion I found, I changed this to piped lines. For example: \\SERVER\ALIASOFMYDATABASE. With this change, now ¡it works!

Named Pipes transport doesn't use TCP/IP.

>I have other customers with networks similar to this one and everything works fine using TCPIP. So I guess, there has to be something that is causing this problem in this case.

That seems like a fair guess. Could you compare the TCP/IP settings between the "good" ones and the "bad ones" and see whether there is a difference.

Another useful move could be to explicitly configure the server's IP address in the hosts files of both the server and the clients. This will prevent a misconfigured DHCP service from stealing the server's IP address when it thinks a Firebird client socket is idle.

>Some time ago I posted this on this forum and someone suggested perhaps the problem is related with TCP/IP protocol or the antivirus. The antivirus is AVG.

If you are using the BDE (or some other interface that caches the output buffers locally) then make sure that the clients' anti-virus, system restore and other utilities are configured not to touch it.

>I tried deinstalling and reinstalling TCP/IP protocol in the server and in one client PC and the problem is still there.
>
>I deactivated the antivirus and the firewall in the server and in one client PC and the problem is still there.

Check that there are no other applications on the clients or the server that use port 3050. (You can configure Firebird to use a different port if that is the case).

>Can anyone give me an idea of what may be causing this?

Only a few ideas to explore, I'm afraid....

./heLen