Error reading socket, ret=10053, errno=2. (778)

[widget1967]

We have a slight network problem at the moment which we are trying to resolve, it could be a PC software problem, perhaps our AV/Firewall software or a physical network issues, but I’m confident we will tack it down eventually.

What happens is this; PC’s once or twice a day momentarily lose their connection to the network, this causes no problems for Outlook, file shares etc as they automatically recover but it causes havoc with our Case Management system and its Progress dB, our users are bombed out with the following error message…

Error reading socket, ret=10053, errno=2. (778)

We use the OpenEdge graphical client 10.2B and I was wondering is there anything we can do to improve resilience, so rather than a crash the client just reconnects to its database session when the network comes back.

I’m afraid I have little experience of OpenEdge, the Case Management system is supported by the company who develop it, but they have been unable to suggest anything other than fix the underlying problem, but that could take time as myself and two support companies are at a bit of loss to explain the drop outs.

Any suggestions would be much appreciated.

Thanks

 

[Cringer]

As far as I know there's nothing you can do. If you lose connection to the database then that's it... unless you're running a fully client/server model in which case it might be possible to trap and deal with... but I suspect that's unlikely.

 

[RealHeavyDude]

AFAIK when that happens it is a STOP condition for the client session - which means it re-runs the first procedure in the session.

Now, it depends on how the databases are connected. When they are connected at start up of the application and the first procedure in the session already references database object ( which I've seen to be very common ) then you are hosed. Full stop. If the database is connected after the session has been started in a dedicated procedure then there is something you might do: You can trap STOP conditions and handle them so that you don't fall back that the first procedure in the session is re-run. But in order to implement this you would need to change the application and introduce a consistent error handling ( trapping STOP conditions ) in all your programs. But there is still the problem that you can just trap STOP conditions but you never know what caused it. Therefore you would need to test whether the database is still connected when you encounter one ...

Heavy Regards, RealHeavyDude.