Steve,

Firstly, Mike is right that it's better to re-arrange this somewhat (you could even use your current Index for a Seek (Exact Off) and Locate Rest While ...). Already for response reasons you should do it. However, this won't explain the error much.

It's my guess that something is around the Descending Order of the Index you use. And I must say, the construction you use is some hard to think over;

The Descending Order causes the Index file to be read reverse. So, the highest key, actually being at the "bottom" of the Index file, is now read first. The dbf will contain all just the other way around, expecting new clockins to be chronologically in the table. So, oldest clockin is at the top.
Now, the Index will start at the bottom of that, and one internal record-fetch of the Locate will give you (theoretically) the last record added in the dbf. A next internal fetch will get the before-last, etc.

I think it is very easy to get confused on the logic here, and that's exactly why you shouldn't do it like this. Think of it :
A GO TOP (with the Index active) would lead you to the last (i.e. newest) record in the dbf. A GO BOTTOM would bring it at the first (i.e. oldest) record in the dbf. So, your implied logic would be : GO BOTTOM - SKIP -1 and you'd be going one record downwards in the dbf, right ? well, I'd rather be a dishwasher then ...

Supposed the above is (correct and) understandable, now think of this :

When a new clockin is added to the dbf, this could be via APPEND BLANK followed by REPLACE ...
Now, at the moment of the APPEND BLANK, there will be a "SPACE" entry in the Index just as well. Where would this record be opposed to the others ? well, in a normal situation at the top of the Index (your DTOC,1 would imply something like 19000101). In your situation it will be (wrink my brain) it will be at the bottom. So when the LOCATE is scanning the table, and it comes to the end, and just after the APPEND BLANK of the other user it arrives at this record ... the value of your forg_date is changed by the REPLACE of the other user, and then what ? Fox shouldn't show that record because it would look rather stupidly. Hence, at the end of the list there would be a higher date than the records preceding it.
What about a "Record is out of range" message here ?

Logically it would fit, though if I were the Fox developer I'd provided some friendlier solution.

The reply could be "but that can happen all the time with replacing values of records in the middle of the file". In theory yes, but in practice it would work differently I think, because that record would be locked (if all is done right) in advance. So the difference here is the APPEND BLANK, which just cannot be locked in advance. I.e., there is always a time gap between the APPEND BLANK and the possibility to lock the record due to the upcoming REPLACE.

Also there would be IMO a difference when your Index would be normally Ascending;
When the APPEND BLANK is applied and then the LOCATE comes in, two things might happen :
1. The blank value is shown at the top of the list, and somewhere in the middle of the list the in between replaced value is shown also (so the record (number) is shown twice in the list !);
2. At the moment the replace was already done just before Locate "wants" to show the blank value, Fox could skip the show of it, when it pre-reads the next Index value. So, the Fox developers could have applied this logic.

See the difference ? whereas the last example has a theoretical solution, the way you work with the Descending Index just hasn't a solution at all.
So, the record to show is out of range. Its implied range.

Please note that I started this as a long shot, but it really could be like this. Note too that the Record out of range as you report it, seems very rare. And Locates (on Indexes) are done all over the place (world). So all 'n all it's my guess that something (in Fox) won't cope with the Descending Index.

HTH,
Peter



>Here is one code example of where the error is occuring. It occurs in the locate statement:
>
>*****************************************************************
>* this procedure checks to see if there is already a clockin *
>*****************************************************************
>cEmpNo=alltrim(thisform.empnobox.value)
>cPayEmpNo='E'+substr((cEmpNo),3)
>lClockedIn=.f.
>cDate=dtoc(date(),1)
>nNow=thisform.zTimeToMinutes( (Datetime()) )
>If upper(right(cEmpNo,1))=='A' and nNow<=240
> &&if second shift and time between 00:00 and 04:00 am
> &&set date back one day
> cDate=dtoc( (date(year(date()-1),month(date()-1),(day(date()-1)))),1 )
>endif
>
>SELECT bcshared
>set order to forg_date descending
>locate for forg_date=(cDate) and alltrim(fnction)=='F1' and alltrim(fempno)==(cEmpNo)
>if found()
> lClockedIn=.t.
>endif
>return lClockedIn
>
>***************************************END OF EXAMPLE
>
>The error happens on win98 or win2000 pro clients. NT4 Server. The table "bcshared" is a fairly large table, it grows at about 20k records per month. I just deleted a lot of old records reindexed and packed. But the error persists. The error only occurs randomly, I havent been able to recreate it myself. But it is being captured in my event log. I have 6 clients running the app and it happens at least once a week, so every 5000 records.