>>That is probably the best way. I was trying to see if I could aviod that. My underlying data structure changed and normalizing forced the spliting up of several tables. If I use two views where I previously use one, I have to (find and) add an additional TABLEUPDATE for each view and have to change the ControlSource of about half the controls on my forms. Pain in the butt but probably no way around it.
>
>Okay, I can see the PITA factor is high. However, why do you need to force the update order? Are there row level rules in place on the child table? Because if you set the appropriate key fields for the view, all tables will be updated when you do the tableupdate.

May be I'm just thinking of this wrong but here is the situation. I have a table X with n number of fields including several character/memo fields. The key field has a default field validation rule to add a new keyvalue automatically when a record is added. I was asked to now make all character/memo fields multilingual. So instead of adding to table X a new field for each language for each character/memo field, I create a seperate table with the structure of:

Key, MField1, MField2, CField1, CField2, ..., Language_id

(there will be one record for each language)

So now I have two tables linked by Key (table1 has only non-language dependent data).

The view is quite straight forward, parameterized on the current language. And updating existing records is also not a problem. The question come when adding a new record. If Table1's key is automatically created, how do I assure that Table2 gets the same key value without having to put a Replace key with ... after each TableUpdate of the view? If I was assured that Table1 was updated before Table2, I could put a default field validation on Table2's to get Table1's key.

If it was only one table I wouldn't even think of this, but I'm dealing with 5 tables, lots of forms and code.