From: "Robert Comer" 

> But as I just wrote in response to your other post, you gave me a good
> idea, I am going to add something to check the system date before
> running the purge, and if it's anything other than one day later than
> the previous one, don't run the purge.   You could do the same thing,
> make a tiny table with one field, which holds the date and time you
> start running the purge.   Every day before you start again you compare
> the current system date to the value in that field, if the difference
> isn't one day, don't run the purge, and send an appropriate message.
> Simpler than that you can't get.    :)

Good idea!  You might want to make it more than a 1 day change though,
maybe a week or two -- there could be reasons the DB would be down for that
long and when it comes back up, you want processing to continue normally.

- Bob Comer



"Ellen K."  wrote in message
news:ag2t0v4264dih1k0gt1d93hg86u30lhf9b{at}4ax.com...
> You restore from the log, not from the backup.   The log will have the
> new calls also.
>
>
> On Fri, 27 Dec 2002 19:45:07 -0500, "Geo."
 wrote in
> message :
>
> >You miss my point, if you come in the next day and start taking calls
before
> >you realize what's happened, now new calls have been added to the db so
how
> >do you restore the old ones without wiping out the new ones? You can't do
a
> >partial restore or a restore missing or anything like that with a
straight
> >database backup. If they were stored as files, you could easily restore
them
> >and then you only have to reconstruct the pointers or restore the
pointers
> >to a second db then copy them to the primary but the bulk of stored data
is
> >in the files so this sort of second db and transfer method is a lot less
> >time consuming. (granted it would work even if the calls were in the db
but
> >it would be much more time and resource consuming)
> >
> >I actually have a reason for asking about this specific example, my sql
> >server had the cmos battery fail, twice the machine date was changed to
> >2048. So I'm somewhat familiar with the problem.  Unfortunately I
don't
> >have the option to store the bulk of the data anywhere but in the db. I
also
> >don't have the option to allow the restore or transfer degrade the
> >performance of the db because then people can't get online.. but then
that's
> >why I'm asking all these questions, hoping to learn something.
> >
> >Geo.
> >
> >"Ellen K."  wrote in message
> >news:bhrp0vgd5c4bl6cu2opuk8vfi86buqqorn{at}4ax.com...
> >> Gaaah.   And you just said you'd rather worry about things that happen
> >> often than things that happen rarely?
> >>
> >> OK, the automated routine deletes ALL the calls, then they get restored
> >> from the backup when this is discovered.
> >>
> >> On Fri, 27 Dec 2002 11:11:17 -0500, "Geo."
 wrote in
> >> message :
> >>
> >> >One day the systems cmos battery starts
> >> >to go bad and somehow the computer date gets changed to
the year 2010,
> >what
> >> >happens that night to the automated routine?
> >>
> >
>

--- BBBS/NT v4.01 Flag-4