>I use Time Stamps in my App and have a Function that retrieves unique Time Stamps.
Without seeing the code I have doubts on the "unique" part being always true. ;-)
SWAG: you are updating from different WS a file server based dbf in a multi-user scenario.
If the clock difference between 2 WS is greater than difference in time lapsed + plus the "wait time" of the loop,
you will find such behaviour. Query a common time server (may be the file server if WS have not all access ti the net) for a
common time to base the WS on and requery as often as it is needed if the clocks are unreliable -
I do it for each WS at full hour + NumberspecificToWS() * 60 mins....
If you are using it for query/update conflict resolution and not for actual datetime/audit-values
I'd opt for a RowID-like usage with an incrementing long for the whole table.
HTH
thomas
>I use Time Stamps in my App and have a Function that retrieves unique Time Stamps.
>
>I have a sitation with one system (so far) that is returning the "The system clock seems to be stuck" message in the code below.
>How is this even possible ?! - And if something wierd is actually causing it, how can it be fixed ?
>
>
>
>
>* MFS_TRAN.TRANS_ID - Contains the last DATETIME() value from the previous call.
>
>ngCount = 0
>timeStamp = DATETIME()
>IF timeStamp > MFS_TRAN.TRANS_ID
> * we're home!
>ELSE
> * This case should only happen if last call was less than a seconds ago.
> DO WHILE timeStamp <= MFS_TRAN.TRANS_ID
> ngCount = ngCount + 1
> WAIT '' TIMEOUT 1
> timeStamp = DATETIME()
> * but lets check it anyway.
> IF timeSTamp <= MFS_TRAN.TRANS_ID .AND. ngCount > 10
>
> WAIT '-- The system Clock seems to be stuck....' + CR + ;
> ' (press any key to continue)' WINDOW TIMEOUT 5
>
> EXIT
> ENDIF
> ENDDO
>ENDIF
>REPLACE MFS_TRAN.TRANS_ID WITH timeStamp
>RETURN timeSTamp
>
>