Legend

Question

Weird issue: Diagnostics: Error Executing Database Query. ''

Forum|Forum|5 years ago
March 9, 2020
2 replies
934 views

UPDATE: They don't know what happened, but it suddenly started working with no errors. CF2016. smh

Hello, all,

The title has the error message that is being sent via email due to error trapping.

The odd thing is that no associated or included page, nor on the page itself, has a query running on the line number indicated (86). I've gone through all of the application.cfc and looked at queries that are in cfcs that are called by application.cfc and none of them are running a query on or near line 86.

The REALLY odd thing is that we have two servers running in failover mode (not load-balancing like you'd think) and the error is happening on only one of them. We've made sure that the webservers have identical configs, and both CFAdmins have identical configs.

Our SA will soon email me the coldfusion and error logs for me to peruse, but I thought I'd get this posted ASAP to see if anyone has any ideas.

This topic has been closed for replies.

BKBK

Community Expert

ColdFusion's format for reporting such "Diagnostics" database errors is:

[Diagnostics: Error Executing Database Query] [Database Driver details] [Error message]

So, the driver details and error message would have been logged somewhere.

In any case, a possible scenario is that your ColdFusion application was going about its business, without any issues. Then a mishap occurred at the database - memory overshoot, failed indices, who knows. Perhaps an idea to check the database logs.

Charlie Arehart

Community Expert

I realize you updated your question with news that the problem seemed to go away. Still, I may have something to help for if/when it comes back.

First, I'll lament with you that CF sometimes gets it wrong in reporting (in an error message) the "line of code" and indeed the "file" that supposedly has the error. (And as for whether "any" code you may refer to (via CFC calls or includes, etc.) may or may not have a cfquery on a line 86, that may or may not prove true.)

But here's what may help you: because you refer to the error as being "diagnostics: " and then the error, that suggests to me that you have an old-school cferror error handler (vs the onerror method of application.cfc, or a try/catch) that is reporting this error.

As such, have your devs change that error handler to add a cfdump of the error scope--whereas for now, they are probably only cfoutputting the error.diagnostics. That one var is of course the LEAST amount of info one would need, but it's what's reporting the number incorrectly.

Instead, if you look at what is reported in the error.tagcontext, or error.rootcause (which are structs, so can't just be cfoutput on their own), those should show an aray indicating what SPECIFIC template was executing, and what line of code, and it's a stack, showing what then called that ("above it", if anything, in the tag/page processing "stack").

And of course, there HAS to be a query running, that HAS to be failing. CF wouldn't get things THAT wrong. 🙂 That said, it may be a cfquery, or a cfstoredproc, or their script equivalents, or an ORM call, etc.

If you do that, and find more specifically what the problem is, do let us know.

/Charlie (troubleshooter, carehart. org)

WolfShadeAuthor

Legend

Hi, Charlie, and thanks for your suggestions.

I had originally set up an onError in application.cfc, but due to a STIG the decision was made to point CFAdmin to a template for displaying a generic error message and fire off an email that doesn't have what I had in place. So, the custom error handling that I created, and which is still in place, is being ignored because _no one_ here will go against STIG requirements - they are taken as gospel. Every once in a blue moon, someone will submit a POA&M if a STIG requirement will break something. But that's rare.

In the error handling I created, I CFDUMP the CFCATCH and CGI structs and email it to the webmaster inbox. We've rarely had any issues with these. I'll see if I can implement some of your suggestions in the template, though. I'm the lead CF dev, here, and I don't always get listened to.

Charlie Arehart

Community Expert

Yep, I should have said that the diagnostics reference (and the implied reference to that as a key in the "error" scope) could have been EITHER because of using cferror OR the site-wide error handler. So you're using the latter, and fair enough.

But yep, I would still be interested to hear when you can add a dump of that to the error handler you have now, and whether it might give the additional detail really needed. Hope it goes well.

/Charlie (troubleshooter, carehart. org)

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded