This is a followup to my post above.

I looked at DT.DBF file containing datetime values with a hex editor and I'm willing to admit that the datetime fields contain more than seconds.

In the example I discussed above, 13 of the records contained this value:

01/10/2000 13:32:22 or 62 68 25 00 6F BE E7 02 in hex

187 (meaning "a lot but I didn't count them all") records contained this value:

01/10/2000 13:32:23 or 62 68 25 00 57 C2 E7 02 in hex

Note that the absolute hex value of the later date-time value goes down.

These hex values differ by:

17 FC 00 00 in hex or 402,391,040 in decimal.

I confess to not having a clue as to why these date-time values which appear to be separated by one second would differ by these particular amounts.

I also executed this command on the fourth record in the DT table:

replace ttest with {01/10/2000 13:32:22}

and it produced the same stored value:

01/10/2000 13:32:22 or 62 68 25 00 6F BE E7 02 in hex


It appears that values returned by DATETIME() are changing in whole second increments so if all of the DATETIME values in your table originate from the DATETIME() function then there should be no problem in comparing equal to a DATETIME() value or to a constant {} value.

I'm claiming that if it doesn't work then the file values have been corrupted in some way.

Peter