> > Yes! cron
> >
> Here is the basic problem w/ using CRON in an accounting situation.
>
> I can't be sure that cron will always be up when the DB is up,
> so lets say crond goes down for some random reason (User, System
error,
> Etc..)
>
> And outside adjustment is made to lets say the equipment account and
that
> adjustment was made on the value of the equipment, BUT it hadn't been
> depreciated because crond went down and no one notice.
>
> Now I have a HUGE issue!
>
> So I have to be sure that all entries/adjustments are made accurately
in
> the time frame they were meant to happen in.
>
It seems that you have a good concern, so I have a suggestion. First,
let me say that if you cannot count on cron to run your stuff at a
certain time, then you cannot count on anything to run your stuff at a
certain time. All of your reasoning for distrusting cron is perfectly
valid in distrusting every conceivable automated system.
Therefore, you have to design your application with the assumption that
your scheduling system is untrustworthy. If you do that, then you have
the freedom to use cron (or some other scheduling system) and build
checks into your database activities to ensure that invalid data cannot
be used if your scheduled processes did not take place.
If you don't want to make changes to existing code, then you can create
a solution as simple as a rule on your essential table(s) that first
checks to make sure the most recent scheduled task was completed
successfully and if it hasn't completed return something that the client
will understand as invalid.
If you're unfamiliar with "rules", they essentially rewrite your query
on the fly. To quote Bruce Momjian's book, PostgreSQL: Introduction and
Concepts, "Rules allow actions to take place when a table is accessed.
In this way, they can modify the effects of SELECT, INSERT, UPDATE, and
DELETE."
I'm sure that you can think of several acceptable solutions if you learn
to distrust your data.
--
Matthew Nuzum
www.bearfruit.org
cobalt@bearfruit.org
