Changing the system date on the Retail Pro server causes failure of scheduled database jobs to run.

Changing the system date on the Retail Pro server causes failure of scheduled database jobs to run. 

The system date on the Retail Pro9 server should never be tampered with. The reason is that Oracle uses the system time of the host Operating System to internally track when scheduled database jobs are to be run next. The next run date for these jobs is based on last run date. If a system has been forwarded dated then set back to the correct current date the next run date of any scheduled database job that was run will be based on that future date, not the correct current date. As a result the job would not run again until the future next run date has been reached.

Scheduled Database Job Examples:

cms_dba.update_mviews;        -- Updates the various materialized views in the DB 
cms_lic.cleanupSeats;              -- Cleans up seats no longer in use by disconnected session

Solution:

At this time the only solution to this issue is prevention. Server systems should be locked down on the host OS level to prevent any manipulation of the system date.
For example in Windows XP this can be achieved by modifying the - Local Security Manager> Local Policies >User Rights Assignment>"Change the system time" security setting.

 

Under Windows 2003 use the Group Policy Object Editor. Go to Start>RUN> and launch GPEDIT.MSC. Once in the editor go to Local Computer Policy> Computer Configuration> Windows Settings>Local Policies > User Rights Assignment> and adjust the Security Setting for the "Change the system time" Policy.

A future release of Retail Pro 9 will detect when the dates have been changed, although it will still be our recommentation that the system date never be manipulated.