GetAsNumber()

[adyf]

If you use GetAsNumber() with a date field is the number returned guaranteed to be unique on any given day? I'd like to use this value in a field with a CandidateID and an AssessorID to give a unique value for an assessment with a certain candidate and certain assessor on the assessment date. I know I will be asked why I am not using an auto entered serial number called AssessmentID, but I'd like to know the answer to this.

[Vaughan]

Dates are internally stored as the number of days since 1 January 0001. GetAsNumber() will return this number.

Not sure what you mean "guaranteed to be unique on any given day".

I can kind-of see what you want to do, but it will (not could) come to grief when (not if) a candidate and assessor meet more than once on the same day.

[Kris M]

more grief if someone resets the system clock...

[adyf]

Dates are internally stored as the number of days since 1 January 0001. GetAsNumber() will return this number.

Not sure what you mean "guaranteed to be unique on any given day".

I can kind-of see what you want to do, but it will (not could) come to grief when (not if) a candidate and assessor meet more than once on the same day.

I mean does each day have a unique value, which I beleive it does according to your answer.

Assessor and candidate won't meet more than once in a day, but thanks for pointing this out.

more grief if someone resets the system clock...

Not sure if this would affect me because CandidateID & AssessorID & Get AsNumber(Assessment Date) are auto entered into the AssessmentID field on record creation and I don't beleive will be altered by a system clock change.

[Vaughan]

Not sure if this would affect me because CandidateID & AssessorID & Get AsNumber(Assessment Date) are auto entered into the AssessmentID field on record creation and I don't beleive will be altered by a system clock change.

What adyf means, and it's a good point, is that a client computer could be set to the wrong date (or there could be a time-zone difference) which means if the key uses the current date, there will be problems.

This can be partly solved by using the Get( CurrentHostTimestamp ) function, which gets the time from the FMS host.

Better solution is to not use dates as keys, particularly if they need to be unique.

[comment]

I believe there are better arguments against the scheme. Otherwise you'd need to abolish all auto-entered dates, times and timestamps...

BTW, one could also validate the field as unique, so a messed up clock would at least call attention to itself.