I'm experiencing an error in my code, but it appears that the genesis for the error is elsewhere. The error I'm seeing is:
(sqlalchemy.exc.InvalidRequestError) Can't reconnect until invalid transaction is rolled back
Problem is, I have a multi-threaded application accessing the database in a variety of spots. How can I identify which issue is generating this error?
I had been using a db.session.rollback() to enable an immediate read from a different user session (thinking it would be fine even if no writes were pending). I was incorrect. I utilized a db.session.commit() even with no pending writes and it enabled an immediate read from a different user session.
Related
I suppose that this is more of a curiosity as opposed to an actual issue, but I thought I'd ask about it anyway. There are times when an uncaught error occurs in a server-side NetSuite script using SuiteScript 2.0/2.1 (2.x), but instead of seeing a "SYSTEM" scripting log entry, there's nothing. It gives the appearance of a script just stopping for no reason. Now, I know this can easily be avoided by wrapping everything within a try-catch block, but that's not what I'm trying to discuss here.
Does anyone have any insight into why a script would just stop without any SYSTEM error logging? It's just something I find interesting given that with the 1.0 API uncaught errors would always get logged. And it's not a guarantee that an uncaught error won't be logged as a SYSTEM log. It seems more common with map/reduce scripts, but unless memory is not serving correctly I believe that I have seen it happen with suitelets and user event scripts, too.
Just thought that I'd pose the question here to see if there was anyone who might know a little something about it.
This is actually covered in the system help for Map/Reduce scripts. They do fail silently. I've not seen this in any other script type.
I have a question regarding error handling practices within SQL Server.
What I would like to accomplish is easy error re-creation. I have a very active SQL Server installation with constantly changing data in the tables I am interested in. It is modeling an active warehouse environment.
I've already built a generic error handler for all the stored procedures on this installation in order to track errors and log specifics about the cause of the error such as:
calling line (this gives the EXEC statement of the stored procedure as well as input variables)
error_message
error_state
error_number
error_line
etc.
What I am missing is reproducibility. Even if I were to run the same statement just a few minutes after being notified that an error occurred, I cannot be sure that my results would be the same due to the underlying data changing.
I would like to capture the state of the data on the database when the error occurred.
This could be something like a database image that I could then import into a clean SQL Server installation and execute the erring line in order to perfectly capture what was happening on the database the moment the error occurred.
Due to the nature of needing to capture this at runtime, I would prefer a light-weight solution. Perhaps only capturing the tables relevant to the failing statement.
Does anyone know if this is possible or has been done before? It is really only critical to try and suss out logical errors. It wouldn't be necessary for something like a deadlock.
I would ultimately turn these data subsets into XML or JSON and include them in the error log when appropriate.
I want to make sure the new procedure valid, insteading of the DB2 always query by the cache pool, I have to rebind the database (db2rbind command). And then I deploy the application on WebSphere. BUT, when I login to the application, the error occurs:
The cursor "SQL_CURSN200C4" is not in a prepared state..SQLCODE=-514 SQLSTATE=26501,DRIVER=3.65.97
further more, the most weird thing is that the error just occurred only once. It will not never occur after this time, and the application runs very well. I'm so curious about how it occurs and the reason why it only occurs only once.
ps: my DB2 version is 10.1 Enterprise Server Edition.
and the sql which the error stack point to is very simple just like:
select * from table where 1=1 and field_name="123" with ur
Unless you configure otherwise (statementCacheSize=0) or manually use setPoolable(false) in your application, WebSphere Application Server data sources cache and reuse PreparedStatements. A rebind can cause statements in the cache to become invalid. Fortunately, WebSphere Application Server has built-in knowledge of the -514 error code and will purge the bad statement from the cache in response to an occurrence of this error, so that the invalidated prepared statement does not continue to be reused and cause additional errors to the application. You might be running into this situation, which could explain how the error occurs just once after the rebind.
I guess by default only error with severity 20-25 will gets logged into SQL Server error log file. How can I change the config to log even other errors which are less severity? Or where I can find less severe errors getting logged in SQL Server? I am interested in errors such as
could not find stored procedure spName
etc.
I extracted the following block from this article, which would be a good starting point to explore the SQL Server error log config changes.
Logging Errors
SQL Server Agent takes these errors from the error log, so if follows that the errors must be logged in the first place. There is no way of attaching alerts to errors that aren't logged. All error messages with a severity level from 19 through 25 are written to the error log automatically.
So, what if you want to log information messages, or messages of low severity? If you wish to have an alert on any errors that are of a severity less that 19, then you have to modify their entry in the sysmessages table to set them to be always logged.
You do this using sp_alterMessage with the WITH_LOG option to set the dLevel column to 128 . If a message has been altered to be WITH_LOG, it is always subsequently written to the application log, however the error happens.
Even if RAISERROR is executed without the WITH LOG option, the error that you have altered is written to the application log, and is therefore spotted by the alert. There are good reasons for wanting to do this, as it will then log, and optionally alert you to, syntax errors that are normally seen only by the end-user.
You can force any error that is triggered programmatically to be written to the error log by using the WITH LOG parameter with the RAISERROR command. So, with a user-defined error severity (9) you can log an incident, cause an alert to be fired, which in turn emails someone, or runs a job, simply by using RAISERROR.
Naturally, because the job that responds to the alert can be run by the Agent under a different User, you do not need to assign unsafe permissions to the ordinary user. You can use xp_LogEvent if, as is likely, you do not want the user to see the error. (Only the Raiserror call can utilize the 'PrintF' formatting placeholders in the error messages, so logging the error with a formatted message using xp_logevent results in a literal recording of the message, string format identifiers and all.)
I would recommend to refer the original article for more/detailed information on this.
Please follow this link to find out more on severities.
In my Zope website I have customized the standard_error_message as a Python script. This script differentiates between error-types and handles redirects for NotFound-errors. For this, it accesses some ZSQLMethods without problems.
Now I wanted to log the NotFound-errors into a mySQL database (yes I know they are logged in Z2.log) and added another ZSQLMethod for this purpose.
Strangely this ZSQLMethod does not work when called from the standard_error_message script. It works (writes into the database) when called from another python script, also when this other script is called per http-request from an anonymous user. If called from standard_error_message, it throws an error if not called correctly but otherwise just does not write into the database (no error logged).
I'm really lost with this issue...
You are running into transaction issues.
Zope wraps all requests in a transaction, and all external database interactions are tied into that transaction too.
This transaction is committed when a request is handled successfully, and no exceptions were raised, and aborted when there was an exception.
The standard_error_message is displayed when there were exceptions; and because there was an exception, your SQL INSERT is rolled back as the transaction aborts.
You'll have to explicitly commit just the SQL transaction; add a COMMIT statement to your SQL method.