>I would keep as much of the business logic as possible in your middle tier server components. Let the database server deal with the storing and delivery of data as much as possible (few or no triggers, few or no stored procedures). As much as this makes sense in your own environment and application.
>
>Use views for all of your table access. With your fox 2.6 tables the views will be local. If you switch to sql server the views can point to remote data. One way to do this is to just change the current database.
>
>Create a data object that has a common interface (save, new, delete) etc. and subclass for local tables, remote tables. You may subclass remote tables to sql server, oracle etc. One of the only differences I can see between local and remote table handling is dealing with primary keys. With local views, my primary key field is updateable (there is a default procedure in the database that works like an identity field) and I call the database procedure to get the next key. With remote data you don't know what the key value is of a newly added record if you don't retrieve that key with a special call. Your data class can handle this transparently.
>
>By using views for all of your data access, you can change the source of the view but your code still acts upon the same name and references and doesn't care where the data came from.

For some reason, I did not think of creating views for the FoxPro 2.6 tables. So, I tried it on a small table and that worked, but when I tried it on a big one (3.7 million records), VFP took forever to open the view. How can I get around this?

Also, I need access to the table's indices (CDX) for querying. How do I handle that without recreating them everytime I open the view?

It sounds like using views will separate the Business Logic from the data. Now, I just need to get it to work.

Thanks again for you help!