Hi,
We have been plagued with this error, ever since we upped the number of concurrent jobs in the DAS from 1 to 2. Although it may be possible to automatically recover from this by using the re-try option, there were other reasons for not wanting to use this.
We have finally found a suitable work-around by using database rules (triggers) to update the status of failed jobs, and re-submit them.
We trigger the update when we see ds_pending_job rows updated from job_status 3 (running) to job_status 1 (failed), and where the new job_error field is set to 2033. When this occurs, we simply update the job_status field to 2 (waiting) and the job_error to 0.
Although other people have reported this “feature”, and the suggested cure was to reduce the number of concurrent jobs, reducing from 2 to 1 was a bit restrictive.
I wondered why we get this problem so frequently with only 2 concurrent jobs. We are using 4.1.2a against an Ingres repository, with DAS running as a service on NT4.
Incidentally, we use another trigger to take a copy of the ds_pending_job row into another table for historical analysis. Using this we can keep the ds_pending_job table tidy, yet report on job run times etc.
Regards,
Rob Blackmoor
Project Manager
Tarmac Heavy Building Materials UK Ltd.
Listserv Archives (BOB member since 2002-06-25)