>Hi,
>
>We are trying to use views for all our tables because we want to have all our apps more prepared for a possible migratio to a client/server environment. Unfortunately we encountered that with view you loose some possibilities you have with working direct on the VFP tables.
>We now are doubting and considering to go back to working direct on the VFP tables. Can anybody cast some light on our discussion.
>Should we learn more about views and should we be able to do everything with them ? Is it indeed easier to work direct on the VFP tables ?, what is better ?
>
>Koos Veel


This is the approach I am taking to development. I don't see any limitations at all to using views. I am using the codebook framework that handles conversion from local to remote data very seamlessly. If you code and design with the philosophy that all your data is coming from remote sources you should not have a problem. Think in terms of data sets. All of your views should be parameterized.

The only differences are dealing with primary keys. I use auto generated integer primary keys on fox tables (using a function in the default of the field) and I use identity columns in sql server. Retrieving this primary key requires a different method between local and remote data, but this can all be handled within a method.

If you are having problems with views or performance, it is a design issue not a view issue.

For instance, in the 'old' days, I used to logically code next, previous buttons on many forms. Now, this practice doesn't make sense. If you have a customer file and are doing edits, why do you need a next and previous. What is the next record? In the new world of sets, you retrieve the customer you want through a selection screen and when you want the 'next' one you enter your criteria of what the next one is. VFP makes it easy to scroll through the customer table but it is not a good practice with networks.