>Thanks Ed:)
>
>>>1. Should application specific tables such as our application registry be also be a view. Does this degrade performance.
>>>
>>
>>Does a view make sense, either to filter some subset of records, present a join with another table, or to permit data entry without automatically triggering field or record-level validation rules that live in your .DBC? If so, then views, particularly parameterized views, may make sense. Not all access demands the use of views, but it makes parameterized retrieval of recordsets easy, can prevent users from directly updating the data table, perform joins so that the join is presented as a flat table without lots of SET RELATIONS/SET SKIPS, and permitting you to enter data for new or updated records and validate them before submitting them to the database, whose stored procedures form the basis of validation in a less controlled fashion.
>>
>
>So in the specific case of our applcation registry or keytable, we are doing none of the above and should leave it as a standalone table with the application?
>
If there are no permanent relations, views, triggers orstored procedures associated with the table, and it operates independently of the basic application schema, there's no compelling reason to include it in the DBC.
>
>>
>>The use of views does simplify the move to a backend on an initial basis; after upsizing data to the backend, query processing for views can be switched to remote views in some cases (eventually, you end up re-writing things either as stored procedures or to directly use SPT to leverage features not available with VFP directly, or to improve data access performance) with relatively little work. I've found that many clients are asking that the application be developed to use the MSDE for the primary database schema, relying on SPT or ADO for handling non-static tables; their take is that it's easier to port to SQL Server from the MSDE than from VFP and VFP .DBCs, especially in terms of triggers and SPs.
>
>What does SPT stand for?
SQL Pass Through
