19.0.33 on Windows 10, SQL Server , DAW drivers.

I'm putting a Hash on every row I save in a particular table.

I call the hash function in OnSaveRecord because the help states that this is where you do logging and such because it's only called if there are changes in the record, and it's called immediately before the save.

At first I thought OnSaveRecord was broken, because I was getting a 1ms difference in the timestamps.

In the existing code there are two timestamp fields. LastUpdate and "CreatedAt". These are updated in update and Creating respectively. I found I was getting incorrect hashes created, and the "detect hacking" code was firing on MOST but not all of the rows created. (I'm logging sensitive data, and hash each row to prove that the data recorded is still as it was when it was collected. )

I logged the "Created time stamp" for the row as it was Created, and got

1/10/2018 4:38:27.243

But when I retrieved the data from the DB and converted THAT to a string, I got:

1/10/2018 4:38:27.242

which is enough of a change to totally scramble the resulting hash string.

To work around this I've added the most godawful appalling piece of code I've ever written.

 Procedure Save_Main_File
        Boolean bChanged
        Integer iFile
        Get Main_File to iFile 
        Get_Attribute DF_FILE_CHANGED of iFile to bChanged
        // now do the normal save behavior.
        Forward Send Save_Main_File
        If (bChanged) Begin // if record is changed at all Do it again so the timetamps are consistent. 
           Reread tTestResults
           Move (HashRecord(Self)) to tTestResults.Ramz
           Set File_Field_Changed_State File_Field tTestResults.Ramz to True
           SaveRecord tTestResults 
Does anybody have a less appalling kludge I can put in here instead?