Micros 3700 WS Crashes w/ Printing Timed Items on Startup 1

[cobbler9]

I am having an issue with a WS5 running with 3700 v5.5 when the WS boots. The WS loads OPS and shows a brief message "Printing Timed Items" and then crashes returning to the CE desktop. We are fairly certain that this is related to a future order a manager tried to enter that included voids on it. OPS crash immediately after entering that check and would not restart (failing to load open checks). We were able to force close the check from the database and that allowed OPS to load but it seems that the WS is still trying to fire the items and crashing.

Oracle (which we pay for support with) has worked on the issue but says that they will need DBA access to fix it. They do not have DBA access to our system and I know for a fact that we were never given the password when the system was upgraded two years ago from a v4.x XP system that I re-licensed with them when we purchased the business. They are going to charge us to send it to programming to recover access even though they never gave it to us.

What has been tried
- Wiping the CF on the WS and running CAL
- Finding the trans_seq's associated with the chk_seq of the broken check and setting the training_status to '10' for those (2) trans_seq (oracle tried this and it appears only one of the two will set to '10', the other stays as '0')
- Wiping and rerunning CAL again

Does anyone have any ideas for
(1) fixing the issue without DBA access
-or-
(2) getting DBA access without paying additional for support that we are already paying for.

This issue also has made our database starts, reloads, and shutdowns take about 8 minutes or longer.

Thanks for any ideas!

 

[Wildbar]

Just a thought. What about creating a new workstation?
I will see about posting getdba later tonight.

 

[cobbler9]

I will definitely try the new workstation possibility when I am back at the site, thank you. Let me know about the posting.

 

[cobbler9]

Thank you Wildbar! Creating a new workstation got the terminal up and running in time for dinner. However, we are still having the extra long database times for startup, reload, and shutdown so if getting dba access is a possibility, I would like to try that as well to fully clean up the mess. Thank you again!

 

[cobbler9]

Just wanted to circle back for a final update in case it helps someone else. Wildbar's suggestion worked perfectly to get the workstation up and running again as a workaround. I was eventually able to achieve DBA access through trial and error based off known lower level passwords. With the elevated privileges, the fix first attempted by Oracle support referenced above (setting the training status to 10) did officially solve the problem.

Advise to others - DO NOT future order a check with voids on it.

Thanks again!