My primary issue is the supervisor does not see or accept new jobs, when new jobs are submitted.

I've had to restore my xserve back to an older backup from a time macine backup, because of a serious crash. First I backed up the job list in /var/spool/qube/job to a server. I restored the HD to an older version. I copied back the job folder to /var/spool/qube/, and I actually rsynced all the mysql folders from yesterday, before the crash, to the new restore. So I rsynced ;

I suggest only enabling the auto-refresh for 'refresh selected' though, to cut down on the amount of data passed between the supe and client on a regular basis.

And no, it's not possible to repopulate the mysql tables from the /var/spool/qube contents.

It should have worked when you copied the old tables in /usr/local/mysql-standard-4.1.22-apple-darwin8.5.1-i386 (as long as the mysql server was not running), but you should have avoided copying the contents of:

/usr/mysql/usr/share/mysql/private/var/mysql

In the future, only copy the qube tables in mysql datadir (usually /usr/local/mysql-standard-4.1.22-apple-darwin8.5.1-i386/data/*qube/), and ensure that the mysql server is not running when you do this.

But if this happens again, I'd recommend just starting over with the qube db's unless you absolutely need to resurrect the jobs for some reason.

When you delete from the duty or assignment tables, specify "WHERE jobid=" and supply the jobid without the ".nn" subjob id: ie, 21820 instead of 21820.19 This will get clear out all subjobs for the job, otherwise you'll have to run the same command for each and every subjob still appearing. In those 2 tables, "id" refers to the subjob, and "jobid" is an easy way to get all the subjobs for a single job in one operation.

It's not the tidiest solution in the world, but it is effective.

It's like using a shotgun to kill rattlesnakes; just don't shoot your foot off and everything's good.