>>>>>>>>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.
>>>
>>>Hi Terry
>>>
>>>Is there any active relationships on this table ?
>>>
>>>If values are different then pointer could be thrown to eof() if infobase alias is engaged in relationship and parent relation (expression) is no longer matched.
>>>
>>>
>>>Also;
>>>Did you chk if values are in fact the same ?
>>>
>>>

>>>Select INFOBASE
>>>if DAYS_OP <>Thisform.cOpDays
>>>   wait wind 'Replacing: [' + DAYS_OP + '] with [' + Thisform.cOpDays + ']'
>>>   &&Simple wait wind check / remove afterwards
>>>   Replace DAYS_OP with Thisform.cOpDays
>>>else
>>>&&pointer should not move and no need to replace
>>>endif
>>>

>>>
>>>
>>>hth
>>
>>Hi Srdjan
>>
>>Thanks
>>
>>Yes, INFOBASE is involved in several permanent relationships, eg the FKs to its look-up tables, and it itself is in a 1-to-m with its parent Route (1 route has several Journeys (INFOBASE) throughout the day)
>>
>
>>Now I know that .cOpDays has not changed, because it only changes when yoy click one of the toggle buttons, and I see the same value stored back anyway. I might as well put your code sample in tough anyway. I guess I was just too lazy in the past :-)
>
>Ok .cOpDays has not changed but was it matched to current record value
>before issuing replace command ?

Well it may not be the same as the record it shoots off to. I'm looking into the reln. thing now.

>
>Did you check datasession for currently active relationships ?
>Permanent relationships (triggers etc) become issue on saving only
>not before that, you would get err message if you broke some but that is different issue (I think).