HelpSpot Help Desk Software | HelpSpot Blog | HelpSpot Support

Query Error when trying to access personal queue


#1

I have one staff member who receive a Query Error: message when trying to access his personal queue. This happened all of a sudden yesterday, and it is not affecting any other users or filters. He can still see tickets assigned to him using a custom filter, but clicking on personal queue simply says “Query Error:” in the box where his tickets should be. What could be the source of the problem, and how can we fix it?


#2

Hi Chuck,

Hmm. Is it known if he modified his columns in My Queue? Can you check the error log and see if there’s anything related there.


#3

These are the system logs from today:

Wed, Jan 18, 2012, 12:18 PM Email Importing Must use comma to separate addresses: Lane - xxxx@xxxxxxx.com class.imap.mailbox.php 206
Wed, Jan 18, 2012, 10:42 AM Database ERROR: operator does not exist: integer ~~* unknown at character 390 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. ajax_gateway.php 2606
Wed, Jan 18, 2012, 10:41 AM Database ERROR: operator does not exist: integer ~~* unknown at character 390 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. ajax_gateway.php 2606
Wed, Jan 18, 2012, 06:58 AM Email Importing Unexpected characters at end of address: ;, xxx@xxxxxxxxxx.com, xxx@xxxxxxxxx.com, xxx@xxxxxxxx.com, 2012@m class.imap.mailbox.php 206
Wed, Jan 18, 2012, 06:42 AM Email Importing Unexpected characters at end of address: , xxxxxxxxx@xxxxxx.xxx

Before that, system logs are from the 16th, which is before this happened. I xxx out some e-mail addresses for privacy reasons.

I suspect the problem may have resolved itself because Artem continued to work on tickets within his queue through a filter, and perhaps if a particular bad ticket was causing the query to fail, but he closed it, and have it removed from his queue, he’s able to access his queue again?

One other piece of clue which may or may not be related is, if I go to advance search, the Detailed tab:

set “relative date since opened” to “today”, and ordered by “date opened” “descending”, the query works fine. If I set the search to yesterday, or last 7 days, etc. I get a:

“Query Error: ERROR: more than one row returned by a subquery used as an expression”

If I set the time frame to last week, the search also works fine. So there really does appear to be perhaps a ticket or something that happened yesterday that is causing HelpSpot to have trouble. I bet the problem is still there, but maybe because the ticket has been closed, it’s not affecting Artem any more.


#4

Yes, I think that’s likely. What database are you on?


#5

It could be that HS_Request_History had 2 rows for one of the requests both marked as fInitial = 1. That can cause query errors and would be something to check. No request should have more than 1 fInitial row in HS_Request_History.


#6

I ran a query against HS_Request_History to look for any xRequest entries that has more than 1 finitial, and I did found a handful. How should these be corrected? Should I simply have one of the two rows removed? Change one of the finitials to a 0 value? Is this something that can be done through HelpSpot’s interface?


#7

Not sure if this has dropped off the radar, but I would like to confirm before I try to change the database data.

Running a query against the HS_Request_History does find a handful of xRequest entries that has more than 1 row with fInitial set to 1. I am not sure if this is a bug in the software that caused this in the past, or whether it’s some odd database corruption. Looking at these problems calls, I either see a duplicate entry for the initial note, or that a note from what appears to be from another ticket attached in there.

I want to make sure it’s save to fix this by changing the fInitial to 0 for rows that I don’t believe should have fInitial set to 1. I want to make sure this won’t break things elsewhere in the system. Or if there’s a better kosher way of correcting these inconsistency, that’s even better.


#8

Sorry I missed this. Yes, each should only hav 1. Ideally the oldest history item but as long as there’s only 1 that’s the main thing.

That should fix it.