The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

My company is currently using SQLAnywhere 9.0 and evaluating 12.0 and we’re seeing an issue with the later version that we’re having trouble resolving.

Calling from our .NET application we’re periodically seeing the following error message: System.Data.Odbc.OdbcException: ERROR [08004] [Sybase][ODBC Driver][SQL Anywhere]Database server connection limit exceeded

This seems to happen sporadically and we’re not clear on the cause. Any insight would be greatly appreciated.


asked 28 Nov '11, 22:55

John's gravatar image

accept rate: 0%

Several good suggestions - now it's up to you:)

(29 Nov '11, 15:40) Volker Barth

If you are creating more than 10 connections with your application, be sure you are also running the server version (dbsrv12), and not the stand-alone engine (dbeng12). The stand-alone server version is limited to 10 connections. (See: )

permanent link

answered 29 Nov '11, 11:25

Jeff%20Albion's gravatar image

Jeff Albion
accept rate: 24%

Your v12 server might simply have not enough licences for the required connection number.

You can use the sa_conn_info() system procedure to check how many connections (and from how many different nodes) are in use currently. And you can use the DBLIC tool to adapt the number of licenses the server can support (obviously restricted to the licenses you have purchased in case you are using a "normal" edition).

What SQL Anywhere edition do you use? Different editions may have different connection limits.

permanent link

answered 29 Nov '11, 02:25

Volker%20Barth's gravatar image

Volker Barth
accept rate: 32%

In .net you should call exlicitly Close or Dispose for the Connection objects you don't need anymore instead of waiting for the Garbage Collection to clean up. Otherwise your connections remain all open (until GC) and might exhaust the server resources.

permanent link

answered 29 Nov '11, 03:10

Martin's gravatar image

accept rate: 14%

Late to the party, but we figured out our problem and I figured I'd post our resolution in case it helps someone else.

Observations: All developers except one could connect to the database server through Sybase Central. The odd man out got the error listed in the OP. However, when all the developers log out and the odd man out connected, then none of the rest of us could connect -- we all saw the error listed in the OP.

In our case we discovered one developer was connected to a different wifi while the others here were all connected through ethernet cable or our primary wifi. It seems SQL Anywhere might have something built into it to try to keep all persistent connections coming from the same subnet.

Edit: On a side note, apparently when the problem-user is using VPN we see the same issue, even though it uses the same addressing as with the other users. Not sure exactly what's going on.

permanent link

answered 29 Jul '13, 13:07

HelpyMcHelperson's gravatar image

accept rate: 0%

edited 29 Jul '13, 13:32


I can definitely tell that this can't be a reason. We connect successfully to our server from 10 or more subnets. Does your server have more than one network interface ? Packages leaving the server are not always go over the default route !

(30 Jul '13, 02:58) Thomas Dueme...

Hmm... Are those all persistent connections from 10 or more subnets (ie. Sybase Central being open and connected from each subnet) or just quick connect/fire/disconnect requests like most web traffic? Does licensing come into play perhaps?

Our development server has one network interface.

(30 Jul '13, 18:20) HelpyMcHelpe...

In case there's some firewall filtering UDP broadcasts between subnets you might want to configure your connection parameters adding HOST=<hostname/IP-address>;DOBROAD=NONE (check the specific syntax for your environtment, this is an example for ODBC).

(31 Jul '13, 03:32) Reimer Pods

If you are running the Network Database Server (dbsrv12), for licensing purposes, client "seats" are determined by IP address. One seat can have as many connections (sockets) open to the database as it likes, but if another IP address connects, it appears as another seat, and the license count is checked.

You should check how many seats you are licensed for on the database server and how your IP network is set up for the number of client IP addresses, to ensure they match.

(31 Jul '13, 09:28) Jeff Albion

I'm have the same problem, but here at my network, I can only connect with 3 diferent machines. The minimum license limit is 10. Someone could help me? Sorry the bad english, I'm from Brazil

permanent link

answered 14 Oct '14, 13:18

Selmerz's gravatar image

accept rate: 0%


That sounds like you have only a 3 seat license. The output of the following query should provide more guidance:

SELECT PROPERTY('ServerEdition') as ServerEdition, PROPERTY('IsNetworkServer') as IsNetworkServer, PROPERTY('LicenseType') as LicenseType, PROPERTY('LicenseCount') as LicenseCount, PROPERTY('MaxConnections') as MaxConnections FROM dummy

(14 Oct '14, 13:56) Chris Keating
Your answer
toggle preview

Follow this question

By Email:

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



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "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:


question asked: 28 Nov '11, 22:55

question was seen: 12,787 times

last updated: 14 Oct '14, 13:56