Is anyone aware of how an mvBase database could execue a command that would
casue the system date & time to be reset?

I was led to understand that mvBase picks up the date and time from Windows
when the mvBase database is started.

Appears the server was not rebooted, nor the database stopped and restarted.
Appreciate any insight anyone could provide.

--
Regards,
Scott

"Scott Richardson" <CheetahFTL (AT) attbi (DOT) com> wrote

On D3 systems, "start.rtc" synchronises the virtual machine clock with the
server clock.

I assume there's something similar in mvBase but can't offer any further
pointers. Sorry.

With Kindest Regards

Mike Wooding

Scott Richardson wrote:
Scott,

What do you mean by "reset"? Cleared? Changed how?
Does mvBASE always loose or gain time?
Is the Windows side correct and the mvBASE side is not correct?
Can you be more specific as to exactly what is going on as far as
date/time differences between Windows and mvBASE?

Dave Weaver

SET-TIME hh:mm:ss (U

is supposed to change the hardware clock in "Pick". I believe the same
command works in mvBase.

Mark Brown

"Scott Richardson" <CheetahFTL (AT) attbi (DOT) com> wrote

mvBase has SET-DATE and SET-TIME verbs that reset the date and time,
and if someone types SET-DATE without a valid argument, it defaults to
12 DEC 1967.

Scott Richardson wrote:
Scott,

What do you mean by "reset"? Cleared? Changed how?
Does mvBASE always loose or gain time?
Is the Windows side correct and the mvBASE side is not correct?
Can you be more specific as to exactly what is going on as far as
date/time differences between Windows and mvBASE?

Dave Weaver

Scott Richardson wrote:
Scott,

What do you mean by "reset"? Cleared? Changed how?
Does mvBASE always loose or gain time?
Is the Windows side correct and the mvBASE side is not correct?
Can you be more specific as to exactly what is going on as far as
date/time differences between Windows and mvBASE?

Dave Weaver

Mark Brown once wrote in <PgJvd.18929$Ew6.14459 (AT) twister (DOT) socal.rr.com>...
Setting the hardware clock is all well and good if mvBase time is more
accurate than the h/w clock or system time. As the time only synchs when
the database service is started, it's easy for the two to drift apart.

From a point of view of synchronising the database time to a reference
time, the only way I could think of doing it is as follows...

Once a day (say), have a basic program that did something like:

TOP:
SLEEP "00:00:00"
EXECUTE "!TIME /T > somefile.txt"
UOPEN "somefile.txt" TO SOMEFILE ELSE ABORT
UREADLINE REFERENCETIME FROM SOMEFILE ELSE ABORT
UCLOSE SOMEFILE ELSE ABORT
EXECUTE "SET-TIME ":REFERENCETIME
SLEEP 300
GOTO TOP

The plan would be to have some external widget (like a Galleon time
synchronisation device [1]) or a NTP client running on the database
server that kept the system and hardware clock up to date. Then, at a
predetermined time, midnight in my example, execute a shell command to
retrieve the (correct) system time via a file, read it and use that to
synch the mvbase time. I don't know - it may be possible to CAPTURE the
shell command output which simplified the program a bit - if not, the
file approach will work.

I've tagged a SLEEP 300 on the bottom on the off-chance you correct the
time by a large amount and move the mvbase time far enough back so the
SLEEP "00:00:00" gets executed again the same day. You could stuff this
on a background port and forget about it. The error trapping might need
a bit of work though :-)

For those of us running time and attendance systems on mvBase, a lot of
drift between real and database time is unacceptable (the users start
complaining if you make them stay late :-).

[1] http://www.atomicclockrugbymsf.co.uk...time-clock.htm
--
David Morris

I seem to recall that mvBase picks up the time/date from Windows on startup
but then keeps control of it's own clock from there on in....

As stated before, you can change the date/time in mvBase using SET-DATE and
SET-TIME...

Regards
Simon
"Dave Weaver" <weaver22 (AT) pacbell (DOT) net> wrote

"Dave Weaver" <weaver22 (AT) pacbell (DOT) net> wrote

Sorry to post and wander away for a day or so. Been busy.
Thanks for all the posts.

It appears a user site suddenly had the mvBase (1.3.02) system
calendar/clock reset approximately 1.5 months ahead of current Windows
Server date and time. Windows was not restarted, nor was it's date/time
changed, mvBase was not restarted. mvBase decided at the cross-over of
12/10/2004 - 12/11/2004, that it was now 1/28/2005 and the time was also
reset to a different time. Things were fine until 12/10 turned over to
2/11 - so whatever happened, was a sharp turn of events

Application had user logons to expire at 12/30/2004 (i.e. require user reset
of passwords by then). Needless to say, applications trying to verify users
logging on, said "password expired".

I got the call from Customer site approximately 12:30 AM, and being rather
tired, fumbled with this for an hour or so w/o looking at mvBase date &
time.I did discover the mvBase date/time difference to Windows OS date/time
early the next morning while querying various files where application checks
for user validation. (amazing what a few hours of sleep will accomplish with
the human body).

I bounced the mvBase DB, and all returned to it's original working
condition, as it re-sync-ed up with the OS.

Windows 200 Server OS was behind approximately 13 Critical Functinality &
Security Patches/Updates, but platform showed no other signs of "hacking".

Best guesss: some user was able to wiggle themselves to TCL and was playing,
either not realizing what they were doing, (or knowing exactly what they
were doing), and discovered SET-DATE and SET-TIME, and decided to perform
some experimentation.

Any other ideas?

Thanks,
Scott