>>He opens the view empty, and inserts records into it from an array. But these records are really representatives of records that already exist in the base tables, so when he does a TABLEUPDATE, he just wants to use the contents of the view to update existing records instead of insert new ones. VFP, seeing that the records in the view were inserted into the view as opposed to populated by a REQUERY(), naturally performs an INSERT SQL when the TABLEUPDATE command is given, and the result is a uniqueness error, because it is trying to add a record that already exists.
>>
>>Since VFP uses the fieldstate of the contents of the view to decide how to perform the update (INSERT vs UPDATE) I have advised him to try to trick VFP using the SETFLDSTATE function to change the "new" status of the records in the view to "current", so VFP will UPDATE the base tables instead of INSERTing into them. The current state of this is an error message stemming from code that I gave him that I can't put a finger on: the code works fine for me. Any ideas along this train of thought?
>
>Erik,
>
>I don't think he will succeed. No matter what getfldstate says the record number in the view is still negative telling VFP that it is a new record.

Lame. I always assumed that it was only using the field states. I have been able to fool TABLEUPDATE before, telling it which fields to set, but have never tried this exact scenario.

>The solution, IMHO, is to use a vierw that fetches the records with SQL and then edit them and update.

This is the way I would handle it too, I just assumed that there were special circumstances that warranted this strategy.

Steve- is this plausible?

If not, then you will need to build an update routine like you were talking about, and try to emulate what VFP does internally, but match which records don't exist to decide when to use an INSERT.