backup options - deleting update jobs/running out of order

 5 Replies
 0 Subscribed to this topic
 68 Subscribed to this forum
Sort:
Author
Messages
Greg Moeller
Veteran Member
Posts: 1498
Veteran Member
    Today we've had what is turning out to be a bad mistake after bad mistake.  What happened:  Payroll staff ran PR197 (close job) in update before running PR195 (accrual).  Staff realized this and attempted to kill PR197 which we all know just makes the job go to "Needs Recovery".
    Staff called me, and in a hurry, not thinking, I deleted PR197 from the "Needs Recovery" status.    Waaah!!  Staff then tried to re-run 195 job, and couldn't because of the 197 still thinks it is running.

    My real question is this:  Is there someone that already has a pre-payroll processing backup procedure in place?  Can one even just do this?  Thinking to avoid the out of order condition by just selectively restoring, and then re-process in the correct order.

    Thoughts, comments, etc?
    Frank Z
    Advanced Member
    Posts: 32
    Advanced Member
      Greg-

      We had this EXACT same scenario at my office. We went to the PRSYSTEM table, and removed the flags for the PR00- Didn't work. We used the delete function on the PR00- Didn't work. Luckily, we back-up after the PR160 is run to avoid burning check numbers. After the restore, everything was fine with the exception of losing a few hours of work.

      We had another instance that we handled a bit differently, before we made backups after the PR160. It is more drawn out, but I'd be happy to share with you in an email.
      Joe O'Toole
      Veteran Member
      Posts: 314
      Veteran Member
        Greg - we had a simlar problem this week with pr198 being run in update mode before pr197. Although the jobs were deleted from recovery, luckily nothing was updated so we were able to manipulate the PR and TA flags in PRSYSTEM and rerun pr197, pr198 and ta199. Frank - what kind of a backup do you do? With all the updates between PR and GL, I can't see how anything short of an entire DB backup as safe and at 40 GB this is not too practical for us during production hours.
        Frank Z
        Advanced Member
        Posts: 32
        Advanced Member
          Our backup was for the whole DB (we are only at around 22GB), and it did take around 3 hours. Lots of work lost on the HR side, but since the lion's share of our other functions are done through add-ins we were able to re-upload the JE's, PO's, etc...
          Joe O'Toole
          Veteran Member
          Posts: 314
          Veteran Member
            Thanks Frank - I was hoping there was some obscure pre-payroll backup solution from Lawson but it doesn't sound like any such beast exists. Our SQL backup completes in about 20 minutes to local disk on the server so we are still considering adding this to our PR process.
            CindyW
            Veteran Member
            Posts: 169
            Veteran Member

              Our payroll staff has a 9 page spreadsheet (yes - NINE) checklist that they follow religiously every payroll.  There are approximately 20 line items on that checklist that instruct the staff to record a milestone timestamp.  We created a script and placed shortcuts on the PR staffs desktops, that will record a timestamp record, such as this one,

              2009-09-04 08:17:23.650
              in a custom  table that the DBA's can use to restore by.  We use it, ALL the time.  It's been a lifesaver.