>>I have a table where I need an index tag with the first character field in accending order and the second field which is a date in descending order. In VFP3 and VFP5 the following tag worked fine.
>>
>>INDEX ON location + STR({01/01/2020}-date_samp,8,0) tag location
>>
>>If I use this tag created by VFP5, VFP6 states that the index file does not match the table.
>>
>
>You're correct that you get the error. But if you then set the order to that tag, VFP 6 recognizes it OK and displays the data in the correct order. An interesting note:
>when you browse the table and the highlight is on a date field, the century shows for the highlighted record, but not for the rest of the records in the browse. I hadn't noticed that behavior before.
>
>>If I re-create the tag in VFP6 it acts ok but the tag does not sort at all.
>
>You're correct here, too. Even if you set the order to that tag, it still doesn't show it that way.
>
>>
>>Is this a bug?
>
>Sure looks like one. There must be some way to get around it, though.
>
>>
>>Is there a better way to do this anyway?
>>
>>Thanks,
>
>I tried creating an index like this and it worked OK:
>
>index on location+STR(99991231-VAL(DTOS(date_samp)),8,0) tag xxxxx
>
>(Not necessarily better, but it works)
>
>If you look at a display status of the table, the first tag (location) shows up with quotes around it. The tag I just gave you (xxxxx) doesn't have quotes around it. I wonder if that's somehow related to the problem?


John appears to be right, that it's VFP6's strict date handling. If you SET STRICTDATE TO 0 and then do the index it's OK. It's even OK to SET STRICTDATE and then use the file and set the tag, you don't get any errors. But you really should use the {^yyyy/mm/dd} format for date constants, as Garrett suggested.