We have a customer which has the problem that from one of his clients the connection through tcp/ip to the database server fails from time to time. Very sporadic and not consistently reproducable.
We have tried ODBC and Sybase native adapter, both show the same behavior.
We have tried providing tcp options like dobroadcast=no;host=x.x.x.x:n providing ip and port.
Pings and other data transfers show no abnormal behavior
If we skip the host= parameter then sometimes the error message says server not found, otherwise its a generic connection error.
Any suggestions on how to analyse this?
asked 21 Dec '11, 11:32
Martin, you haven't included the SA version, build number and platform for either the client or server, nor have you included the specific error message you are hitting.
It sounds like Martin is having issues where connections sometimes fail, while Bill is having issues where the connections sometimes drop. Is that true?
Martin, if your client is specifying links=tcpip(host=dobroadcast=no;host=x.x.x.x:n) (or simply HOST= in SA 12) and failing that sounds like it may be an underlying connectivity issue with the OS or network. If you had the output from a LogFile=file file of the failed connection with these parameters that may give more information. Posting the full connection string (with UID/PWD removed), the server command line, and the LogFile output may give some clues. If this was happening regularly, you could add -z to the server and perhaps get more info from the server (I realize that this is sporadic).
answered 22 Dec '11, 10:09
I could be a millionaire if I could solve that problem! Or I would personally fly to Waterloo to present a gold plated certificate of appreciation if I could get anyone at iAnywhere to take an interest in creating a solution!
We have run into it periodically over the last years. AFAIK, it has always been transient network problems: bad cables, bad NICs, flaky routers, duplicate tcpip address, etc, etc. Windows long ago learned that they had to be robust enough to just re-connect whenever a connection is lost. But SQL Anywhere creates a stateful connection to the database (and that sounds like a GOOD idea for security reasons!) So anytime the connection is momentarily interrupted, the database connection is toast.
So it's not really SQL Anywhere's "fault". But since all the users other software continues without a hiccup, they quite naturally think our stuff stinks.
I have sometimes been able to diagnose the core problem by: 1) looking at workstation and/or server event logs for anomalies, visually inspecting cables and connections at frequently offending computers, gettting the techs to run cable certifiers on the flaky computer. Other times I am stuck with trying to convince the customer "they" have to fix something that none of us can see.
maybe you will be lucky enough that the errors show up in one of those tools!
answered 21 Dec '11, 16:56
i've seen the same behavior with ASA8 if the server has a "fast" nic and the client has a "slow" nic (ex: client is a 10 and the server is 100/1g or client is 100 and the server is 1g). i haven't had the problem with ASA 11 or higher. we skipped 9 and 10 so i can't comment on those versions.
if you can get the the problem to show when the client requests a large amount of data (running a report with many rows) you MAY "cure" the problem by turning off the auto detect speed on the nic card on the client and set it to a slower speed.
answered 22 Dec '11, 07:11