>I'm afraid I still don't understand (and please bear with me). If you buffer tables, and apply the same restrictions to data entry as you do to your forms (all required fields must be filled, e.g.) then I can't see the advantage to using views exclusively.

Well, first of all, I don't apply restrictions to my forms very often, I believe that's what we have the .DBC for; iow, my users can pretty much write what they please when creating new records, knowing that I (.DBC) only let them save that data when they stop messing around. But still, by making changes on views, the time that the original table spends in edit mode, i.e. attempt to replicate data from view, has been brought to a minimum. Users can still go back, correct the input and try again, but the role table has here is to accept/reject data, not be in an edit mode while everything happens


>Are you sure you're not talking about using unbuffered tables (which I would never do, either)?
>
>>You also made a good point, one that I neglected to cover, in your previous posting, namely Client/Server applications.
>
>This is the most frequent reason given for never using base tables, but it simply doesn't apply in all (or even most) cases. I would suggest that most databases are single-user, single-client apps for mom and pop businesses.
>
>If you're working with medium to large-sized companies, then it makes sense to use views for everything, I suppose. Otherwise...

Companies I work with are pretty much XL-sized, in the context of this country, of course.