I've been trying to run a dynamic query inside a cfquery tag. Previously it was running fine.
So now, I can see the debugger enter the cfquery tag, but it does not finish running. It didn't seem to have made an affect to the database, since nothing was added for that insert query. Putting try & catch blocks didn't catch anything.
When I looked at the Server Monitor, under Statistics ->Database -> Active Queries -> and sure enough it is listed as an active query.
My other cfqueries tags are running fine though.
There is no problem on the database side.
I've tried changing the content of the tag to run a non dynamic insert query, but it results in the same thing. When I've changed the content of the query to a badly formed sql, it does catch the error.
Would you suspect this to be a ColdFusion problem?
Post your query. There is going to be something horribly wrong with it. My gut instinct says deadlock or cross join.
Related
I'm using PostgreSQL and all queries have been working fine for all our users. Except now. Some hours ago, some of the sentences are not working for some users. For instance:
select comments from appointments_appointmentlog where id=102501539;
If I run this sentence in the psql tool, it runs just fine. But, I use a different id (one of the problematic ones), then it gets stuck:
UPDATE appointments_appointmentlog SET comments='A' WHERE id=30042047;
The select command works fine though:
select comments from appointments_appointmentlog where id=30042047;
Any idea what may be happenning? Do you need any additional information? Also, as a side note, I can update, create and delete other rows in the same appointments_appointmentlog table.
Note: not sure if relevant, but we are using Django 1.1 (I know I know, too old). The problem can also be reproduced with raw sql though, without using django.
Edit
As #a_horse_with_no_name said in the comments, it is a lock:
LOG: process 3637036 still waiting for ShareLock on transaction 2604361155 after 4413702.724 ms
DETAIL: Process holding the lock: 3635781. Wait queue: 3637036.
CONTEXT: while deleting tuple (429566,2) in relation "appointments_appointmentlog"
STATEMENT: DELETE FROM "appointments_appointmentlog" WHERE "appointments_appointmentlog"."id" IN (30042047)
Not sure how to unlock it though.
In SSDT project (using VS2017/VS2015, SSDT version 15.1.61702.140), I cannot get my project to build. The compiler keeps complaining about the sql statement in my PostDeploymentScript (yes, I have set the BuildAction property to PostDeploy). The sql statement is:
if ('$(env)' = 'dvp')
BEGIN
PRINT 'creating users for dvp'
:r .\SecurityAdditions\usersdvp.sql
END
ELSE IF ('$(env)' = 'qat')
BEGIN
PRINT 'creating users for qat'
:r .\SecurityAdditions\usersqat.sql
END
The actual error message is:
D:\My\File\Path\PostDeploymentScript.sql (lineNum, col): Error: SQL72007:
The syntax check failed 'Unexpected end of file occurred.' in the batch near:
The line num referred in the error message in the last line (end). Any idea what's causing this?
Apparently the problem was due to the GO statements I had in the files I was referencing. Having GO statements inside if else block is invalid. Here is an article explaining that. I was able to get it work by removing all GO statements from the referenced files and by splitting if else to two if.
IF ('$(env)' = 'dvp')
BEGIN
:R .\SecurityAdditions\UsersDVP.sql
END
IF ('$(env)' = 'qat')
BEGIN
:R .\SecurityAdditions\UsersQAT.sql
END
GO
I had this same error because I forgot to end one of the scripts being included in the post deployment script with a GO statement. What makes it hard fix is that the error will point to the first line in the next script instead of the script where the GO statement is missing.
I ran into this issue while I was trying to create database users in a SQL Database project. Setting the build action to None is no use because then your script doesn't run during the deployment.
I was using a script like this to create the users:
IF NOT EXISTS (SELECT * FROM sys.sysusers WHERE name='$(DbUserName)')
BEGIN
CREATE USER [$(DbUserName)] WITH PASSWORD = '$(DbPassword)';
ALTER ROLE [db_owner] ADD MEMBER [$(DbUserName)];
END
I had two SQLCMD variables in the project file and setting a default value for one of them actually resolved the issue. It's really weird but I hope this helps some poor soul one day :)
I would like to share my experience here.
I got same error building my sql project but scenario was different and tricky.
I introduced new column in one of my database table and I needed to populate that column for already existing rows in that table. So basically it should be one time process and hence I decided to create post deployment script to do that. This post deployment script
began with IF condition to make sure it run only once for a given database. Please note this does not allow GO statement.
then Create Function to create temporary function. This needs GO statement before Create Function mainly because it makes changes in database schema. This was tricky because IF does not allow GO statement.
then Update query using temp function to achieve my requirement. This is fine without GO statement
then DROP FUNCTION to remove temporary function. This is also database schema change and ideally needs GO statement.
To handle this situation without any GO statement
I created a variable let's say '#CreateFuntion NAVARCHAR(MAX)' and set it with whole Create Function statement.
Executed Create Function using "EXEC sp_executesql #CreateFunction". This runs Create Function in separate batch. I was expecting Drop Function will need same treatment but in my case it worked without GO and "EXEC sp_executesql" may be because it was last statement in the script and would anyway run in next batch.
Everything else as it is
Another reason this could happen is if a post deployment script has a BEGIN statement without a corresponding END line. In such a case, any subsequent GO in anther future script will cause this error. I stumbled across this due to my own absent-mindedness when editing one of the post-deployment scripts.
I am having no joy with the RavenDb profiler. There's output rendered in the browser, but the profiler always claims there are no requests and no sessions.
When the document store is created I make the following call:
RavenProfiler.InitializeFor(docStore);
And in my master layout I have this, just before the closing body tag:
#Raven.Client.MvcIntegration.RavenProfiler.CurrentRequestSessions()
As far as I can tell there's nothing more required in order for this to work (of course, I may be wrong) yet the output of the profiler is always as above.
I'm using version 3.0.0.0 of Raven.Client.MvcIntegration.
Any ideas?
I figured it out. It was an issue with how I resolved the DocumentStore via my Windsor Container. It turned out that I ended up with two instances of the DocumentStore, and the wrong one was registered with RavenProfiler. Once I ensured that only one DocumentStore was created, everything started working as expected.
I have a "DatabaseError: current transaction is aborted" that comes and goes (to be specific, 11 times out of 841) in a Django 1.3 project using Postgres. The project is a quiz site and the error occurs when a user submits the answer form in the view. From the database's perspective, the process involves a number of queries and looks like this:
Gather all of the correct answers for the question (they are multiple choice and may need more than one answer)*
Grab the user's profile
Save this answer
Query for the user's new point total
Save the total to their profile
Check to see if they qualify for a new reward
Award new reward if they do
Somewhere in that tortured process, this error crops up (I'm guessing because one query isn't waiting for the others). Is there a way for me, in production (i.e., DEBUG = False), to log the database errors just in this case? I'm on WebFaction and the Postgres error logs are not available to me. Could I steal something from this middleware example to fire in just this specific case?
Alternatively, is there a better way to find this error or should I be wrapping the individual queries in transactions (unfortunately they aren't all in the same place in the code, not sure if wrapping the view in a transaction decorator would help)?
*Just to confuse matters, the multiple right answers requirement was added in the middle of development and then dropped right before we went live, so I could simplify this process somewhat, basically skipping steps 1 and 4, but I'd like to know a general answer to this sort of mysterious issue.
You haven't said where in your 7 steps you have transactions that begin and end. That would be helpful to know.
One source of "transaction aborted" messages is due to deadlocks. More details would be in the PostgreSQL logs.
But the bottom line is that you will continue to have a painful and time-consuming experience debugging PostgreSQL if you can't get access to your PostgreSQL error messages. Take that up with WebFaction. If they can't helpful and your time is worth much, your bottom line costs will be lower by moving to an environment that provides this fundamental feature.
You have to enable autocommit for the transaction. In your DATABASES entry, include:
'OPTIONS': {'autocommit': True,},
By default, Django opens a transaction at the first query. By using this option, you manually have to start a transaction (e.g. using #commit_on_success). Since there is no transaction open anymore, you'll get the actual error that was previously masked by the transaction error.
The autocommit setting will be the new default for Django 1.6, see https://docs.djangoproject.com/en/dev/ref/databases/#postgresql-notes
Would it be ok to get a CF app to check for a valid database before proceeding to process that request?
This is because there may be instances where the database server may be down or being upgraded, hence an error comes when a db dependant request is made.
If there is no connection to the db server, the user can be safely redirected to a safe page.
Or can cfcatch work?
How can this check be done?
Thank you.
in your onRequestStart method of your Application.cfc file or in an Application.cfm file you can run a simple query to check that the database is available. Wrap the query in cftry/cfcatch. If the query fails, you can redirect the user in the cfcatch, if it succeeds, you can be reasonably sure that your database is "alive".
I've used such a check in one project. Code may looks as follows (not sure if it will work in versions of ColdFusion lower than 8), consider this sample as chunk of UDF written in CFScript:
// service factory object instance
factory = CreateObject("java","coldfusion.server.ServiceFactory");
// the datasource service
dsService = factory.DatasourceService;
// verify the dsn
return dsService.verifyDataSource(arguments.dsn);
Oh, I have even found small note in the code I wrote on my old laptop couple of years ago:
// [performance note] this server check takes 1-3ms at local PC (Kubuntu 7.10, CF8 + Apache2, Sempron 3500+, 1GB RAM)
While time looks like small I have found out that doing this check on each request is not really useful for my application. Any way I have a habit to use the try/catch extensively for errors handling. But if your datasources may cheange frequently it may have more sense.
Adding an extra query to every request to make sure that the database is up is a patently bad idea. A better approach would be to build a "maintenance mode" switch into your application, that you would manually enable when you are doing planned maintenance (upgrades, etc).
If you want to have a "friendly" page displayed when an error (like database issues) occur, then use the onError() method in Application.cfc and/or the <cferror .../> tag in Application.cfm, as a global error handler.
If you are worried the db could vanish, I would implement a "SELECT 1 AS A" query in your OnRequestStart handler that runs only every N minutes. This can be accomplished by using the query caching feature. I'd start with performing the query every 30 min.