cancel
Showing results for 
Search instead for 
Did you mean: 

How to analyse sporadic connection problems

MCMartin
Participant
4,316

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?

Accepted Solutions (0)

Answers (3)

Answers (3)

ian_mchardy
Product and Topic Expert
Product and Topic Expert

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).

MCMartin
Participant
0 Kudos

Version is 11.0.1.2405 and we are currently in the process of upgrading the customer to 11.0.1.2713. Your interpretation of the problem is correct, for me if a connection is established the rest works successful, it is just the establishing which fails. I will consider using the LOG= parameter, thanks for the suggestion

Former Member

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!

MCMartin
Participant
0 Kudos

Thanks Bill for sharing my frustration 😉

reimer_pods
Participant
0 Kudos

We have designed our software to automatically try to reconnect if a SQL statement fails with "connection terminated". But of course that will work only for short network interruptions.

VolkerBarth
Contributor
0 Kudos

...and it requires that you have cached the credentials, methinks - or would it also display a connection dialog?

reimer_pods
Participant
0 Kudos

Yes, credentials are cached and used for all subsequently created connection within a session.

ian_mchardy
Product and Topic Expert
Product and Topic Expert

Bill, as you probably know, SA may dropping your connections due to a liveness timeout (the other end [client/server] doesn't send any data within the liveness timeout, and it should be sending liveness packets at least every one half of your liveness timeout). Have you tried increasing the liveness timeout on your connections to see if that causes connections to drop less often?

If you open a support case, and tell tech support that I have a simple client and server programs that send somewhat similar packets to a CmdSeq connection's liveness packets, we can provide these programs to you, including their source code. This may demonstrate more simply what the problem is.

t1950
Participant

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.