Re: Middle-Tier Inflicted Corruption
- From: Hemant K Chitale <hkchital@xxxxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 04 Feb 2004 21:48:55 +0800
Does/did PeopleSoft pick the date from Application Servers or Clients [as
in "User's PCs"] ??
Scary and quite dangerous not to rely on one central location -- the
database -- for dates.
It is like allowing multiple sequence generators to generate numbers for
the same Sequence.
Hemant
At 04:27 PM 02-02-04 -0800, you wrote:
>I haven't had much sleep lately. The other day someone came to ask why
>our Financials Peoplesoft database thought it was 1998. I checked to be
>sure, and the database returned the correct date. I asked them to check
>the client, which in this case is a Citrix farm. Some of those servers
>showed the 1998 dates. The maintainer of that system was queried and replied:
>
>
>"The problem with the clock was due to the old domain controller not
>correctly synchronizing its time with the new domain controller. Which is
>another good reason for building a new domain controller. Because the
>clocks never properly synchronized, when the new domain controller came
>online to backup the failing primary it came up with a time that was out
>of date. This has caused the domain time to be out of sync. It was a
>last vestige of the old domain controller 'OVERLORD'. I apologize for the
>problems it has caused you. If you have any questions about this please
>let me know."
>
>
>
>Peoplesoft (in-the-head) in their ultimate wisdom decided not to use the
>date on the database server, but that on the client. I now have these
>incorrect dates sprinkled through the system. Furthermore some have
>propagated from parent to child. I spent most of the weekend mining redo
>logs and believe I have come up with a complete list of the effected
>rows. One cannot ever be 100% sure. The project leaders for each
>Peoplesoft module have these. They will be responsible for implementing
>any corrections
>
>Peoplesoft does not use database enforced referential integrity. However
>it does employ unique indexes and calls them primary keys. These keys can
>include dates. If the date of a parent table is corrected in this
>situation and the children are missed, those children are now orphans. If
>a child's record is changed and the parent's missed, same thing. If the
>dates are not changed then reports are incorrect. Perhaps a capital asset
>get's an incorrect receipt date and the depreciation schedule is thrown off.
>
>With database enforced RI I can find the lineage of a key through all
>generations, but that is not so easy when it is program based.
>
>I am open to suggestions as to how to best remedy this stituation
>
>
>Ian MacGregor
>Stanford Linear Accelerator Center
>ian@xxxxxxxxxxxxxxxxx
>
>
>
>
>
>
>
>
>
>
>
>
>----------------------------------------------------------------
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>----------------------------------------------------------------
>To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
>put 'unsubscribe' in the subject line.
>--
>Archives are at //www.freelists.org/archives/oracle-l/
>FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
>-----------------------------------------------------------------
Hemant K Chitale
Oracle 9i Database Administrator Certified Professional
http://hkchital.tripod.com {last updated 24-Jan-04}
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
