>>Kenneth,
>>I see this as a Trigger problem and not a child view problem.
>>
>>From what you are describing, you are never (or rarely) going to update the language dependent information by itself. You are going to update the language independent version and that needs to be propagated to the language table.
>>
>>Add an Insert and Update trigger for the parent table. The trigger will know the Key field and also the situation (Insert/Update) and it can add or update records accordingly.
>>
>>HTH.
>>
>Yes it is a trigger problem but this is where I'm getting lost. I will never be updating the language dependent information (Childtable) alone only in conjunction with ParentTable but the inverse is true for the ParentTable . The question is when I add a new record to the view and then do a TableUpdate. The view will create a new record in both tables. ParentTable's key will get the new key value from the Default Value rule. I could then put an Insert trigger in the ParentTable to pass the new key value to the ChildTable, but what happens if the record in ParentTable is created first? The Child Record won't exist yet so it won't know where to put the key or will put it into a different record. I could also do the same with the ChildTable but the same would happen if the ChildTable record is added first.
>
>I'm probably just spacing on this completely.
>
>Thanks for taking time on this, ken

Ken,
Going back through this thread, it looks like all the information you need for your application is stored in the parent table. The child table is merely a reflection of parent information translated into different languages. I may have been thinking too far in the future for my own good but I thought there was some type of automatic translation mechanism. The trigger would call this function and update/insert the appropriate fields in the child table.

If this is not the case and you want to go with one view, then you could call the NextID function explicitly when you add a new record to your view. Or it could be the default value at the view level instead of at the table level. When you add the record to the view, the default value function will kick in. Then you only have to do a little pre-processing to retrieve that value from the PK field and populate the FK fields in the same view.

The default value won't (or shouldn't) fire for the table because the value is already specified.