John,

The base table is being opened for specific reasons but is not being updated. Even if it was being updated it would not cause a situation where the index is not being updated when the fields associated with the index were updated. If the view and table were both updated (view, then table), the views changes would update the table's buffer and then the table changes would be written to the table and index. When the non-updating anomoly was originally discovered the base table was not being opened independently.
-myron kirby-
-----------------------------------------------------
>Myron ---
>
>If the view is open and updatable, you do not have to open the base table and if, for some reason you do, do *not* allow any direct updating of it...it'll just get you into these situations. :-)
>
>>
>>You are correct in that if you have a view and the base table both open in the data environment you have to update the view and then the base table. I do this in my form save routine. If you do not update the base table after the view then you get an uncommitted change error and neither the data or indexes are updated.
>>-myron kirby-
>>----------------------------------------------------------
>>>Myron ---
>>>
>>>I searched through the MS KB and couldn't find any reference to this type of error. But it does bother me that the table and view can be opened simultaneously and directly updated simultaneously. I have to believe that there is some architectural issue at work here and not a VFP bug. If you have the base table open and have a buffered version of it ion an updateable view, TABLEUPDATE() the view without otherwise updating the table, the table will not show the record.
>>>
>>>>
>>>>I am not sure of the specific question, but the same instance of the application can have the table open as in the view. It should not matter what or who has the table open. Once changes are committed to the table either directly or thru the view the associated indexes should be updated. The indexes are not being updated after a FLUSH or after the application has been closed.
>>>>-myron kirby-
>>>>------------------------------------------------------
>>>>>Myron
>>>>>
>>>>>*But* can the same instance of the application have the same table open as is open in an open view?
>>>>>
>>>>>
>>>>>>The field values are being updated, the indexes do not appear to be updated. This anomoly persist even after the application is closed and the tables are used by other users. The only way to correct the situation is to rebuild the indexes.
>>>>>>-myron-
>>>>>>=====================================
>>>>>>>Myron ---
>>>>>>>
>>>>>>>Is it possible that you have the base table explicitly open and buffered as well? If so, if you issued a TABLEUPDATE() on the base table *after* you had on the view, changes via the view may be overwritten.
>>>>>>>
>>>>>>>
>>>>>>>>I have a view consisting of 4 tables that updates 1 of the base tables. The view is being used on a form to update 3 fields. The problem is that the view commits the changes correctly but the update tables indexes apparently are not being updated correctly. After the update is made I can go to the base table and see the changes but when attempting to try to do a SQL Select with a Where statment based on the field value, the record is not selected.
>>>>>>>>
>>>>>>>>If I manually change the field to a different value and back to the changed value it will start working correctly. As a work-around I have had to save the updated value and the OLDVAL of the view and then update the base table with a REPLACE statement with the OLDVAL and then the new value.
>>>>>>>>
>>>>>>>>Also, if I delete and rebuild the indexes with the new values are then corrected.
>>>>>>>>
>>>>>>>>VFP5.0b on WIN98 and WINNT.
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>myron kirby