>>>>For some reason the replace code below seems to send my file pointer to the last rec.
>>>>I was at top (got INFOBASE open in browse window as I go thru debug)
>>>>I scrutinised every command and no movement.
>>>>As soon as the replace happened I saw the browse shoot to eof()/bottom
>>>>I've reindexed the table (which always has a CDX open anyway - no IDX)
>>>>
>>>>

>>>>Select INFOBASE
>>>>Replace DAYS_OP with Thisform.cOpDays
>>>>

>>>>
>>>>Anyone any ideas what the kinell's going on here? I'm not sure this always happens as some have been successful.
>>>>
>>>>'ppreciate it
>>>>
>>>>Terry
>>>
>>>Did you have index based on DAYS_OP and that order is current for the table?
>>
>>Hi BB
>>
>>Thanks for getting back.
>>
>>There is quites a complex index in operation:
>>
>>rte_no + rte_let + directn + var_code + days_op + j_start
>>
>>Note that Days_op is part of it. However the value of Days_Op has not changed so I don't see how this would change the order.
>>
>>Having said that you've just prompted me to consider what would happen if I did!
>>
>>Do you still think this might make a difference?
>
>
>How the value is not changed if you have:
>

>Replace DAYS_OP with Thisform.cOpDays
>

>It will be no changed only if Thisform.cOpDays is equal to current DAYS_OP in the table. But if Thisform.cOpDays = DAYS_OP than your table should be no reorganized.
>BTW both way the record pointer must be the same. REPLACE move record pointer only if you set some scope in it (NEXT, ALL, WHILE).

There are some toggle buttons on the form, one for each day of the week ("days operating" of the bus). These feed a form property: .cOpDays whenever they are changed. So when saving a record I ensure that it has the latest .cOpDays.

I have been concentrating on other settings in the record, fed by listboxes from look-up tables. I have not changed the operating days.
So what I meant was the value in DAYS_OP had not changed from what it was in this case, so I wouldn't have thought this would change the table organisation.