The server was audited and the driver is there, although I'm not certain if some people require a different driver than what is being provided:

-rw-r--r--  1 root root 694K Apr 25  2009 mysql-connector-java-5.1.7-bin.jar

This is in the path /usr/java/jdk*/jre/lib/ext/ although some staff might not be familiar with the path for these shared JDBC drivers.

When I replied to your post here in another thread, I checked the server after you mentioned it as being the JDBC driver and should have came back to that thread to indicate I had done so afterward. I apologize if this then resulted in a very long discussion on the ticket system and details beyond the scope of the driver replacement itself.

Of note, very few staff in our system have the access to re-add or fix any drivers or components on shared systems, but I do have such access.

Thanks.

I agree that customers should not have the last word in setting the priority on a ticket, either through picking a priority or forcing an escalation. While I don't have any access to the ticket queue (I'm only a customer myself), I have seen plenty of forum posts with subject lines URGENT! EMERGENCY! END OF THE WORLD! HELLLLLLP! and the question was "how do I change the background color on such and such a page?". People are greedy and self serving, or have no sense of proportion, and will do stupid things like that, so it should be up to the support staff to determine priority. You don't let patients run an Emergency Room, coming in with a headache and demanding priority on a CAT Scan. You let a triage nurse evaluate incoming patients and decide who needs to be seen first.

Now, if support actually lacks a way to set priorities, and for Political Correctness reasons is treating every cut finger and shotgun blast as the same priority, well, that would be stupid. I hope there's some way to flag serious issues (server down, for example), based on the sound judgment of staff (or supervisors), and get to the most critical items first. As less critical requests (how to change a color) age, their priority should tick upwards so that they eventually are gotten to.

The ticket system should be fixed so that bumping a ticket by submitting two replies in a row doesn't result in being sent to the end of the queue (penalized). Why can't the system use the timestamp of the first reply in a string of replies? That is, when adding a reply to the queue, check if this is two replies in a row. If so, use the older reply's timestamp (keep the actual newer timestamp for documentation purposes, but use a hidden timestamp for setting priority). It's silly to force people to log on to a helpdesk system and edit an existing ticket in order to add new information, when they could more easily just send a new reply.

Finally, LP doesn't seem to do a good job of informing its customers about what's going on. I see a lot of forum posts complaining about not hearing anything for many hours on end (12 -- 24 -- 36...). Naturally, the assumption is that the ticket has fallen through the cracks, and sometimes it turns out that has happened. Customers would be much more comfortable if LP guaranteed a next response of some kind within X hours (possibly depending on current support load and priority of the ticket). It doesn't have to be a fix in 4 hours, just some indication that the problem is being worked on. Couldn't there be a timer that pops up a (partially prefilled) email for the tech or supervisor, where they could fill in a few words giving the status, and send it off? That would be very reassuring to customers and keep them happier (and not clogging the ticket system and forums). For the ticket queue system, this status update would not normally count as a helpdesk response (unless the tech asks for information, and marks it as a response).

Also meant to mention in my previous post: the feedback@lunarpages.com is a joke.  I've used it several times and might have well sent my feedback into a black hole for all the good it does.

I totally agree - I can't tell you how many times I've gotten responses that make it clear the ticket wasn't really read.  Maybe if everyone sends such feedback to the feedback email they'll realize there's a problem.  One person giving feedback seems to be ignored but there's strength in numbers.