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's gravatar image

Martin
8.6k119151237
accept rate: 14%


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

permanent link

answered 22 Dec '11, 10:09

Ian%20McHardy's gravatar image

Ian McHardy
3.1k23354
accept rate: 38%

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

(22 Dec '11, 11:34) Martin

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!

permanent link

answered 21 Dec '11, 16:56

Bill%20Aumen's gravatar image

Bill Aumen
2.1k344674
accept rate: 16%

Thanks Bill for sharing my frustration ;-)

(22 Dec '11, 02:29) Martin

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.

(22 Dec '11, 03:52) Reimer Pods
Replies hidden

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

(22 Dec '11, 05:38) Volker Barth

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

(22 Dec '11, 09:09) Reimer Pods
2

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.

(22 Dec '11, 10:17) Ian McHardy

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.

permanent link

answered 22 Dec '11, 07:11

Tom%20Mangano's gravatar image

Tom Mangano
632212636
accept rate: 6%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×132
×10

question asked: 21 Dec '11, 11:32

question was seen: 1,930 times

last updated: 22 Dec '11, 11:34