All databases need ONE network time

[HazMatt]

I'm developing a time tracking / job costing / punch clock solution in FileMaker pro 6.0. We are running FileMaker Server on a Windows NT box, hosting to Macs & PCs.

I want to design the system as airtight as I can, so as to prevent "clever" users from changing their computer time to increase their paycheck or whatnot. I need one constant time to achieve this, and the NT server seems to be the logical "timekeeper".

Is there an external function that I can use to tap into the FileMaker Server? Are there any better ways of doing this?

[Anatoli]

IMHO no problem on Windows network. There are functions for this in system and change of clock can be also disabled.

Give Macs to nice reliable users and the PC to the bitchy ones

[HazMatt]

LOL, well, even though that would be funny to explain why the switch of computers, that won't work.

[trevorg]

I can't give you the definitive answer, but I do have some suggestions.

For the Windows side: If you are running a properly configured windows network where everyone has permissions assigned you can remove the ability to change the time on the computer completely. You can create a login script to sync the time to the server by using the Net Time command.

An example would be: Net Time ServerToSyncTo /s /y

If you are not running a windows domain, but merely PC's in a peer to peer setting, you could use the exact same command inside of FileMaker using the "Send Message" script step. This is just like running the command from the "Run" command inside the start menu. One would have to be careful though, because you can't verify that the operation was successful. If this is viable, you could run this command to sync the time prior to performing the script to record timestamps. (and would therefore reset the clock if someone changed it). Perhaps you might even want to capture the current time before resetting it to see if someone has moved it (or if any particular computers clock is drifting beyond an acceptable amount)

As far as the Mac goes. I think it would require applescript. I'm not versed in Applescript, but I know Microsoft has provided an extension for the Mac (pre-OSx) to sync the time with an NT Server. That extension was on the NT 4.0 Resource Kit. If you could locate that, or some other type of extension that you could therefore applescript to get it to sync the time to a server. You *might* have a successful kludge to do what you are desiring.

[keshalyi]

Well... now, I'm not sure, but this seems to work for me. In both 9 and X, I believe, there is an option to synchronise with a network time server - in fact it comes built in with the ability to sync with Apple's americas time server, so that its something out of the building that noone can muss with - and yes, it does compensate for time zone, so you cna use this anywhere, if you have your time zone set and such. In OS 9, it depends on how you have your comps set up. The best way is to set them up in Multiple Users, then, once you have it set, take the Date and Time Control Panel, put it in the Control Panels off, and then lock the folder down so noone but the admin can muss with it. In X, I haven't tried it, but I think you can lock other users out of darn near any control panel you want, so you should have that same option.

[HazMatt]

Thanks for the suggestions. Currently I am sort of ignoring the issue until I find a solution that is acceptably elegant. I don't really want to try to administer several different computers

[CobaltSky]

Some time back I roughed out a design for a multi-user time syncing system for a client. In the event, it was never built, however the approach might be one that you would be interested to consider. I've managed to locate my notes on that design.

The system was to be dependent on use of the Troi Activator plug-in, and required a pair of files, one of which, TimeMaster.fp5 was top run on the server, and the other, TimeSlave.fp5 was required to be installed separately on each workstation.

An opened file on each workstation made a call (from within it's start-up script) to a script in the local copy of TimeSlave, which in turn did the following:

1. Created a new record for the current date (date and time stamping it.

2. Opened the TimeMaster File from the server (as client).

3. Using a relationship between TImeSlave and TimeMaster based on Workstation ID (UserName), accessed a record in TimeMaster specific to the current workstation (and if none existed, created one) and cleared the CurrentMasterClock field in that record.

4. Invoked Activator to send an external call to the server IP address to trigger a script in TimeMaster (with the workstationID being passed as a parameter via the activater comms call), which located the TimeMaster record for the current workstation and performed a Set Field ["CurrentMasterClock", :Status(CurrentTime)"] command on that record.

5. Meanwhile TimeSlave, after issuing the Activator external call, enters a loop with a 1 sec timed pause, which checks for a value in the TimeMaster::CurrentMasterClock related field.

6. As soon as a value in TimeMaster::CurrentMasterClock is detected, TimeSlave exits the loop, sets the current record CurrentSlaveClock field to it's own system clock time using Status(CurrentTime), then transfers the value from TimeMaster::CurrentMasterClock to a CurrentMasterClock field on the current record.

7. A stored calculation on the current record ('LocalTimeError') has the formula CurrentMasterClock - CurrentSlaveClock. It automatically updates to reflect the values places to those fields by the script.

8. An unstored calc on the current record in TimeSlave called MasterTime has the formula Status(CurrentTime) + LocalTimeError.

9. All calculations and scripts throughout hosted solutions which make a call to Status(CurrentTime) were to be updated to call instead to TimeSlave::MasterTime (via a constant relationship reverse sorted on record ID, so that it always picks up the most recent value). Auto enter options using a time value were to be changed to auto-enter calc equivalents using adjusted time.

It has to be acknowleged that the system has an inherent error which is due mainly to the comms delay in the current network. In the implementations envisaged, the network topography was such that some tests showed the error range to be within 3 secs. In that instance, the client was prepared to tolerate accuracy to within 15 secs, so the solution appeared viable and well within range.

Different networks and/or accuracy requirements might produce different outcomes. In a purpose-built application, the functions of TimeSlave might best be incorporated within the opener file itself - but this is a design consideration. The notes I prepared for this one used an 'add-on widget' approach because that was the client's preference.

It's important to concede that this approach is a work-around rather than a full 'solution', since it does not actually re-set the local system clock. That means it is only as good as its implementation - if some time values are left unadjusted in the solution files, then time comparisons will be inaccurate. Also time values accessed or provided by applications other than FileMaker will be unadjusted. These were unlikely to be an issue in the implementation for which the idea was conceived, but could be for others.