Greetings, Tony -
I suspect you are somehow hitting a limitation of Sybase OpenClient, not the DBMS server or PowerBuilder. How many connections is one instance of your PB application attempting to open?
You are assuming the total number of connections made to the DBMS server is being exceeded, but I do not think that is what is going on in this case. The error may instead be referring to the number of connections made using your PC. OpenClient may have a modest default limit on the number of simultaneous connections it can handle running on a single machine/Windows login.
"ct_connect" is the name of a function in the Sybase OpenClient database communications software that runs in your machine. OpenClient provides the communications pathway between the DBMS and the apps running on your PC, such as your PB application. You may need to research this in SAP/Sybase OpenClient documentation or Q&A forums.
Regards, John
Since the .Net assembly is handling the ASE connection ...
Is this built using the old PB .Net Assembly or one built using the new SnapDevelop IDE included with PB 2019 Rx?
Did this problem start happening recently or is this an on-going issue?
Since the .Net assembly is called from a WS, does it Disconnect and Destroy SQLCA upon its return to the WS?
Regards ... Chris
The built still using the old PB .Net Assembly in PB 2017.
The problem is an on-going issue it happened 2 or 3 times on PROD it blocked the PB client.
The PB .Net Assembly connect and disconnect in PB source code and compiled it as PB .Net Assembly.
Here list a sample using in our project as below:
Transaction dbconnection
dbconnection.Database=xxx;
dbconnection.LogPass=xxx;
dbconnection.ServerName=xxx;
dbconnection.LogId=xxx;
dbconnection.DBMS=xxx;
dbconnection.dbparm=xxx;
dbconnection.AutoCommit=xxx;
Connect using dbconnection;
Invoke retrieve data function.
Disconnect using dbconnection;
destroy dbconnection;
That code looks pretty straight forward. The only thing with the older PB.Net Assembly object approach is that it was not thread-safe. So I wonder if adding a Yield() command right after the "Destroy" command might help to make sure that the current .Net Assembly thread has fully cleaned up the DB Client resources before the next thread of this NVUO starts? Just a a thought.
Regards ... Chris