>>In order to make a view updateable there must be a primary key on the underlying table. This is required so that the original record can be found and updated by the TABLEUPDATE function. While your view may consist of fields drawn from multiple tables, you may only wish to update one table from the view. You do this by selecting only the fields that are made updateable. When it is time to update, you can issue a tableupdate command.
>>
>>In the update criteria tab, you mark the fields you want to make updateable, and also the fields that are part of the primary key of the underlying table.
>
>Thanks Bob, that's the best explanation I've read anywhere ;). I'm going back to look at my views and see if I can get some key fields in there. How does this work when you're using other views as data sources? Are the keys the ones from the original tables that created the first views?
>
>I guess I'm thinking you join Table1 and Table2 to make ViewA, then join ViewA and Table3 to make ViewB. Would the key fields be fields from the Tables?
>
>Mandy


I would think, first of all, that it is best to provide views that relate to one table only when you are using that view for updates. However, you may also include a second table for situations where codes are used. For instance, you may have an updateable view of an invoice detail table that includes the description of the line items joined to a description table. This field (from the description table) would not be updateable while the code (from the invoice detail) would be.

If there is a one to one relationship between the records in Table1 and Table2, chances are you can create an updateable view that updates both tables. IF you use ViewA to create a new view, you will see the underlying field names in the update criteria section. The system 'knows' which tables are actually providing the data.

I have been doing this mostly with remote SQL Server Data. When I issue a tableupdate the command actually generates SQL Statements such as UPDATE .... SET .... WHERE primarykey = ..... etc. There is one such statement generatedfor each table that is being updated for each row that is being updated. If the where clause cannot identify a valid record, the update fails.

For those who are interested, I ran into a problem today where SQL passthrough, calling a stored procedure that updated and inserted new records, was generating the same date time stamp for records being added with multiple calls. (down to the same 1000th of a second). I would say that this implies very fast ODBC performance