>>>Ok, clueless that I am, I don't believe I have buffering on my views. I understand the general idea of buffering but could someone explain this as it relates to views (and how I do it)?
>>
>>A view works like a table. If you apply a buffer, when doing TABLEUPDATE() on it, the data will be saved into your related tables.
>
>Ok, that makes sense.
>
>>>Two things to note: (1) some of my views actually come from the joining of another view previously created and a table. Does this affect anything?
>>
>>It should work.
>>
>>>(2) I'm a bit confused with the View Designer's "Update Criteria" tab options. Specifically, I don't have any one key field(s) in these particular views. A combination of all 4 fields in the view results in a unique combination/key. I'm not sure then if I can use the "Key Field" and "Updatable" switches for my views. I've assumed I can't thus my rationale for trying to save the form data to the tables via code.
>>
>>In order for the view to be able to update a field, it needs to have a key field. Otherwise, it won't be able to know the relation record.
>
>I was afraid of that. Do you know of any workarounds, i.e. code or anything else, to then save the data my users enter onto the form back into the appropriate original table?
>
>Mandy


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.