It does help performance in retrieving records into a view and updating records if you have indexes on the key field[s] and any fields used to filter the data in the WHERE clause. A view is just a SQL command that returns a cursor. This cursor then gets some special properties set based on meta data stored in the DBC.

A view can be of one or more tables. If multiple tables are to be updated, then you have to define what field or fields make up a unique way of identifying each record in each table. If the view is of multiple tables, but only 1 table is to be updated, then you only have to define the key field[s] for the table to be updated. An example of this type of a view is where you have a parent table with a field that is a foreign key to a lookup table whose data is typically static. The view is created to actually show the description from the lookup table instead of the FK value. In this case, there is no need to updated the lookup table.

The easiest way to see how VFP creates views is to, of course, create one in your DBC, then run GENDBC, then look at the code created by GENDBC. This utility [APP] is found in the VFP HOME() + [Tools\GenDBC] folder. This app will create a PRG of all the code necessary to create the DBC and all of the objects in the DBC including connections, tables, views, indexes, PKs, FKs, and stored procedures.

>Hello All,
>
> Need an explanation on the key field definition. Is the key an image of your indexes from the table and can you have more than 1 in a view. What if an index is made up for two fields. Based on what sort my user is choosing I need to replace records based on how they found the record so my index could be different for each user? How would I handle a replace using the view. I have checked off all the fields which are part of my indexes is this the correct way. Any good books to help me understand using views?
>
>TIA