Forum search

[eeyore]

When I used the forum search function today it returned the following:

 

Following query failed:

DELETE FROM dcsearchcache WHERE session_id = '4424d2bd469c490b' OR UNIX_TIMESTAMP(search_date) < UNIX_TIMESTAMP(NOW()) - 3600

[LovesYng]

I tried AOL, Internet Explorer & Firefox. Worked fine all three times on my end. Good luck..

 

When in doubt I whip it out :+

[Boston Guy]

I'm getting the same error, more or less, when I try to "Read New". It's consistent between IE and Firefox.

 

Also, obvious steps like logging out and in again, clearing the browser's cache and rebooting the system have no effect on it. It's been consistent for about 24 hours now. My assumption is that there is a problem with the cache used by DC Scripts.

 

BG

[+ deej]

Obviously, any time you get an error message about a SQL query it's a server-side issue. Nothing to do with you, your computer, your browser, the color of your carpet, or what you had for lunch.

 

Daddy will fix.

[Boston Guy]

Well, yeah, but the IT guy in me wants to take immediate steps just to do something. :-)

 

Not to mention the fact that no one else had mentioned the error, so I wanted to be sure it wasn't some weird thing on this end...

 

BG

[+ deej]

>Well, yeah, but the IT guy in me wants to take immediate

>steps just to do something. :-)

 

Understood. And we share that trait. :-)

 

But one of the most valuable traits I look for in IT personnel when interviwing is the ability to quickly zero in on ownership of a problem. I won't hire the guy who's going to spend hours and hours spinning his wheels trying to fix something caused by an external system that he can't touch.

 

Pinpoint the problem. If it's not yours, point! }(

 

This one is on the M4M server(s). Nobody needs to panic about viruses or trojans on their computer. It's ours and we own it.

 

Daddy will fix.

[Boston Guy]

>>Well, yeah, but the IT guy in me wants to take immediate

>>steps just to do something. :-)

>

>Understood. And we share that trait. :-)

>

>But one of the most valuable traits I look for in IT personnel

>when interviwing is the ability to quickly zero in on

>ownership of a problem. I won't hire the guy who's going to

>spend hours and hours spinning his wheels trying to fix

>something caused by an external system that he can't touch.

>

 

Agreed. But, then again, it's worth spending 5 minutes determining that it's not your problem. :-)

 

 

 

>Pinpoint the problem. If it's not yours, point! }(

>

 

Well, I did that, eventually. But I didn't for the first 24 hours because I try to be patient when people are providing free systems. :-)

 

>This one is on the M4M server(s). Nobody needs to panic about

>viruses or trojans on their computer. It's ours and we own

>it.

>

>Daddy will fix.

 

Yup. And he already did.

 

BG

[eeyore]

Everything is working fine now. Thanks for the prompt fix.

[+ deej]

>Agreed. But, then again, it's worth spending 5 minutes

>determining that it's not your problem. :-)

 

Sometimes. You also have to know when that 5 minutes starts. :-)

 

I have a co-worker that jumps the gun and goes off investigating based on incomplete information, spends hours chasing down rabbit trails based on incorrect or incomplete assumptions, and just generally makes himself look foolish. He's determined to find it and fix it, but he's not really sure what it is.

 

Meanwhile, I've refused the bug report for incomplete information and sent the boss back to the support staff for clarification. Nine times out of ten, the response that comes back is "never mind".

[eeyore]

That old SQL query bug is rearing its ugly head again it seems:

 

Following query failed:

DELETE FROM dcsearchcache WHERE session_id = '4441685e3e97db47' OR UNIX_TIMESTAMP(search_date) < UNIX_TIMESTAMP(NOW()) - 3600