We have issues calling external functions in our database. It seems to be related to the fact that we initiate the procedure calls from an external .Net application using the System.Data.Odbc provider. When we call the same procedure multiple times, we sometimes get errors with the message : ERROR  [Sybase][ODBC Driver][SQL Anywhere]All threads are blocked
The external function is :
And the C# code executed in the dll is :
It is obviously used to determine if the specified datetime is in daylight saving time range or not.
We use the latest version of SQL Anywhere 16 (18.104.22.1685).
We are able to reproduce the issue in a simple .Net Console application. I will post the source code here if it can help understand the problem.
Any idea how we can fix this while still using ODBC connections?
asked 08 Nov '16, 18:00
I can also reproduce this with the following non-ASP code.
My first attempt at a reproducible connected once and iterated the command 1000 times with no issue and then disconnected.
This version is connecting/disconnecting on every iteration. I'll check into this.
answered 09 Nov '16, 16:16
While we are looking into this problem, consider this workaround implemented in C++ (well mostly C).
The SQL interface is (you'll have to change the path below):
and the expected argument is a string, for example:
answered 18 Nov '16, 16:05
first: Are you familiar with the thread deadlock (http://dcx.sap.com/index.html#sa160/en/dbusage/deadlock.html*d5e46598) phenomenon?
answered 08 Nov '16, 18:50
Here is the code of the sample application I made to reproduce the issue. It uses .Net Framework 4.
And the sample procedure :
Edit : One little note that may help to find the problem, if we change the Provider name to "System.Data.Oledb", the issue does not happen and the execution is much faster.
Is there some reason to avoid using the technique shown in the SQL Anywhere 17 CLR samples folder?
C:\Users\Public\Documents\SQL Anywhere 17\Samples\SQLAnywhere\ExternalEnvironments\CLR
using Sap.Data.SQLAnywhere; using Sap.SQLAnywhere.Server;
answered 15 Nov '16, 08:28