>>Not necessarily so. I had databases populated by other apps and my job was to access them (pun intended, the other frontend app was written in Access, 2004) from VFP and get things in order as much as possible. So VFP's datetime lacking ticks (amputated around VFP5-6) doesn't mean the ticks must be entirely absent.

Agree that if ticks matter then to make use of parameterized VFP queries you'd need to use a less than bound on day+1. Very easy if you're using RVs.

>>... in the last three milliseconds, because if that made any difference, the designer of the database should have used datetime2. As it is, it's either included in the current day (time portion not greater than 23:59:59.997) or belongs to the next day.

Agreed- the low tick sensitivity and very recent base date seriously reduces the utility of datetime.. but it's all there was pre SQL Server 2008 and if you don't need ticks, it ain't broke. FWIW, datetime2 allows you to specify 0-7 subsecond digit precision and uses 6 vs 8 bytes if you specify 0 precision.

>>Let's err on the side of the benefit of a doubt (if I may be allowed to mess with phrases, it's a weekend) and assume that Cetin did have a real life situation where it mattered, and earned a few gray hairs over the problem. We all had such times.

That's fine = so either 997 with between, or a date upper limit with implied 000 ticks. Not sonmething to get ticked off about. ;-)