>This was the way it ran under their FPW2.6 app and it worked okay. They continue to have their old app "hit" against these tables as we are starting to switch to their new VFP app. The new VFP app does not (yet) include code to handle an abandon. But when it does a regular INSERT of a new record, it finds all the abandoned records in the table and fills them in with the Plaintf_ID of the correctly inserted record. That is, if I inserted a record above where File_ID was 2348 and Plaintf_ID was 6677, the new record is inserted correctly but along with this, VFP does an update of all rows where Plaintf_ID is equal to zero. Funny thing though, it only updates the foreign key field and does not touch the file number or any other fields.
>
>For now, the way around it was to change the old app so that it inserts a bogus Plaintf_ID into the record so that it is non-zero (since it is a numeric column, I just stick in a -9999 as there are no negative ID's to join to in the Plaintf_ID column. This will work (somewhat) but it would have been nice to understand what VFP was doing. Maybe somehow it's INSERT does something like APPEND a blank and then it does an UPDATE for all records where the foreign field equals zero (this doesn't really make sense though - I could see it doing this for the primary field [File_ID] but not for a foreign key field.
>

It could update the FK if there is any RI between the tables.

How is the record getting into the view? Is it with an APPEND or an INSERT? Even if with an INSERT, is the INSERTed value 0 or the id? (Just double checking)

If there is any RI and if it's getting into the view as 0 and somehow getting updated back to the table -- any record pointer movement will do this for row buffered views, even w/o TABLEUPDATE() -- before the pk is set to the correct non-zero value, the zero-valued fk's will be updated in the child table with the new pk from the parent table.

A couple of ways to track it down
1) just step through after firing off the code that adds the new record
2) Back up your data, then set one of your parent table record's PK to 0. When you add a new record in the view, if it indeed is writing back to the table while the new record's pk is 0, you'll get a Primary key violation. At least you'll know it's getting updated as 0.

HTH