I made an application in .net, it is C#, which the main objective is to execute several stored procedures at the same time, and it works. But i had proof this application with a stored procedure which inserted about 40000 registers, and it worked.
So i decided run the application with the real application which it has to work, and it fails, it raises an error; this is the error:
ERROR [HYT00] [INTERSOLV] [0DBC SQL Server driver] [SQL Server] ct_results(): user api layer: internal Client Library error: Read from the server has timed out.
The stored procedured is executed but not completely.
I'm working with framework.net; Odbc.net and Sybase 10.
The strange thing is that i have proof the same Stored procedure with VB6 and also Odbc and it works very well.
I run the stored procedure in a query analizer and it works wery well, it seems that the problem is Odbc.net ot .net
I have proof the stored procedure with Thread and also without thread object and it happens the same thing in both cases.
The stored procedure execute a lot of instruction, inserts, updates, transactions, and also execute other five stored procedures which one of them execute a bat file (with internal sybase stored procedure xp_cmdshell), this bat file (file.bat)
updates some tables, and execute other application which communicate with another application in another server througth a socket, this is a very very large stored procedure.
This is my code in C#.
/* Para compilar creando un exe
* csc /nologo /out:ThreadPrueba.exe /r:Microsoft.Data.Odbc.dll ThreadPrueba.cs
internal class ClaseEjecutar
public void ejecutarFuncion()
string strConexion = "";
string strComando = "";
//int elementos = 0;
In theory, the deadlock won't go away, whatever you do on the client. Make sure you always update the tables in the same order. Even a Select can deadlock with a series of Updates, if the Select joins the tables in the opposite order.
In practice, deadlocks can be made much less frequent if your client works faster. This applies in the case when the transaction is started at the client, so there are a number of round-trips between client and server during the transaction.
I knew many projects where the ODBC driver for Sybase was causing all sorts of problems. The first component which really does the job is the OleDb 2.7 driver for ASE.
Now, I'm now sure how could you use that. From what you wrote, there is obviously a bridge from ODBC to .NET. Is there a similar bridge between OleDb and .NET ?
And, if you wait a month, you will get the new ASE.NET Sybase driver. If it speeds up the client-server communication, then your transactions will become shorter, and the chance of deadlocks will be reduced.