In Sybase, we are intermittent exception like
System.Data.OleDb.OleDbException (0x80004005): [08S01]
[ASEOLEDB]ASE is terminating this process.
at System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling(OleDbHResult hr)
at System.Data.OleDb.OleDbCommand.ExecuteCommandTextForMultpleResults(tagDBPARAMS dbParams, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)
at System.Data.OleDb.OleDbCommand.ExecuteReader(CommandBehavior behavior)
or
System.Data.OleDb.OleDbException (0x80004005): [08S01]
[ASEOLEDB]Sybase Connection died while writing to socket. Socket returned error code 10053.
at System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling(OleDbHResult hr)
at System.Data.OleDb.OleDbCommand.ExecuteCommandTextForMultpleResults(tagDBPARAMS dbParams, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)
at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()
The number of records in the table is less than 200K and queries are typically inline inserts or select with temporary tables
After the disconnection, we need to recycle the thread or bounce the process.
Do we need to change at Sybase configuration end? Or inside the application process?
This is likely an issue on the side of the ASE server. Check out the ASE errorlog file, there should be a stack trace with clues as to why the process was terminated. Depending on what you find there, you may need to contact TechSupport and get the latest patch, or incrementing certain ASE config settings might also help.
I generally have seen this error phrasing when the connection is a victim of a deadlock situation. If that's the case it should be in the ASE error logs.
Here we have a generic WinSock "10053" error code, displayed from the OS where the .net (ASE, Oledb, etc...) client is calling the DB.
It is possible that you find nothing in the ASE error logs (unless you activate a specific user tracing), because the server is closing the connection in a standard way, while the Sybase client software has cached its request and is still writing to the windows socket (btw, yes, it is a bug/issue: you could search the latest information on EBFs and software maintenance or open a new support request).
I've had this problem when creating a temporary table (from .Net ASE Client dll): possible cause is that the local temporary table get dropped if the connection is returned to the connection pool (in fact the error was present each day at the first trial). I've tried turning off the connection pooling in connection string and that worked for me.
Data Source=myASEsrv;Port=nnnn;Database=myDB;Uid=myUsr;Pwd=myPswd;Pooling=False;
Related
I have a SlashDB installation on top of MySQL. Once in a while, especially after a period of time of inactivity, the first call to an API returns:
'ResultProxy' object has no attribute 'execution_options'
The second request (same endpoint) would work normally.
My guess was that SlashDB's connection to MySQL had been terminated due to inactivity. I set the wait_timeout system variable (MySQL) to about 10 hours and it seems to help in some cases.
What does this error mean, and is there a way to prevent it?
This should no longer occur in version 1.0, but in case you still have a problem please post a dump of your database schema with your question.
I'm using Play 2.6 with Scala, and something in my program is eating up the connections to my Postgresql database. I keep getting:
PSQLException: FATAL: sorry, too many clients already
In my console. I've checked my max connections with
show max_connections;
And it's at the default of 100, but I shouldn't be eating up this many. Any time I access the database in the application, I use the suggested:
myDB.withConnection { conn => \... do work with SQL here ...\ }
block, which according to the documentation, should release the connection once it escapes the the block. I don't think anything is getting stuck in a loop, as otherwise other pieces of my code wouldn't be executing. Unfortunately, the stack trace that's printing only shows the "behind the scenes" stuff and won't show what caller is establishing the DB connection. Any ideas on how I can find the offender?
I'm using play-slick with slick 3.0.0 in this way:
I got a connection by
val conn = db.createSession.conn
then got statement:
val statement = conn.prepareStatement(querySQL)
and return ResultSet:
Future{statement.executeQuery()}
But I got a problem: I tried to use this query about 50 times, then, I got the exception:
SQLTimeoutException: Timeout after 1000ms of waiting for a connection.
I know this may caused by connections are not closed and I didn't close the connection or session in my code manually.
I want to know:
Will connection create by my way close and return to connection pool automatically?
Was my situation caused by connection didn't release?
How to close a connection manually?
Any help would be greatly appreciated!
Remark: It would most helpful, if you post your full code (including your call that is performed 50 times)
Will connection create by my way close and return to connection pool automatically?
No. Even though Java 7 (and up) provides the so called try-with-resources (see https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html ) to auto-close your resource. ,AFAIK, this mechanism is not available in Scala (please correct me somebody, if this is not true).
Still, Scala provides the LOAN-Pattern ( see https://wiki.scala-lang.org/display/SYGN/Loan , especially using ) which provides a FP way of closing resources finally.
Was my situation caused by connection didn't release?
As long as you don't provide your full code, it is only a guess. Yes, not closing connections make the connection pool exceed, thus that no new connections are available eventually.
How to close a connection manually?
connection.close()
I have a SqlBulkCopy operation that is taking data from an MS-Access 2007 database (via OleDbConnection) and using SqlBulkCopy to transfer that data to a SQL Server database. This has previously been working and continues to work for one MS-Access database, but not the other.
I get the error message:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
It is hard to believe it is a timeout ast the oledbCommand.CommandTimeout = 0 the sqlBulkCopy.BulkCopyTimeout = 0 and on either side (MS-Access and SQL Server the timeouts have now been set to 0).
Are there other issues/exceptions that the above error message could be hiding? Is there a way to determine what the base cause of a sqlBulkCopy.WriteToServer exception is (there doesn't appear to be any inner exceptions etc...)
So the issue was that there were dates being transfered and some of those dates were invalid for SQL, but valid in Access. For whatever reason this was presenting as a Timeout rather than "invalid date/time" - though if you reduce the data being transfered to a handful of rows (200) rather than the full transfer (500,000) it reports as invalid date/time ... curious.
Is there a way to check if a database connection is open? I am trying to check the connectionState but it shows ConnectionState as Open even when database is down.
private bool IsValidConnection(IDbConnection connection)
{
return (connection != null && connection.State == ConnectionState.Open);
}
While I don't have an answer, I can tell you why stuff like this happens
It basically happens with any protocol above TCP that does not send periodic heartbeats.
TCP provides no way to detect that the remote end is closed, without sending any data, and even then it can take considerable time to detect the failure of the remote end.
In an ideal world, the server would send a TCP FIN packet when it goes down, but this does not happen if someone yanks out the network cable, the server crashes hard or an inbetween NAT gateway/firewall silently drops the connection. This results in the client not knowing the server is gone, and you'll have to send it something and assume the server is gone of you don't receive a response within a reasonable time, or an error occurs (typically the first few send() call after a server is silently gone won't error out).
So, if you want to make sure a DB Conenction is ok, issue a select 1;` query. Some lower level DB APIs might have a ping()/isAlive() or similer method that could be used for the same purpose.
That looks like the correct code to check if your DB connection is still open.
I would expect to see an exception thrown on your connection.Open() when the database is down. Is the database down before you open the connection or does it go down after the open?
a simple way would be to code a button with query, of retrieve some data from some table of the database, if an error is returned catch it.
that would show if connection there or not.