>Hi, I have a VFP6 (SP5) application that opens a local VFP database that purely consists of remote views. As we all know, this database can become corrupted by PC crashes, [Crtl][Alt][Del] etc. Questions:
>
>1) Is there any way of opening the database and trapping the fact that it is corrupted so that the application can automatically recreate the remote views?
>

Buy SDT (Stonefield Database Toolkit) - you can run a validation of all tables/views/indexes against a set of metadata which defines the properties of database and free table objects. It can repair a good deal of damage that it might detect through reconstruction of headers, indexes and the like, and can determine that a variance exists between the metadata which describes what is expected and the harsh reality of what's sitting in the tables and DBC.

>2) Is there any method of changing the way remote views are recreated? Currently when recreating remote views, each view seems to be generating an SQL command of "SELECT * FROM table" which on large tables and on a WAN can take a long time (several minutes).

You can delete the RV and then recreate it using CREATE SQL VIEW or a tool like Erik Moore's eView to alter the base SELECT statement and then use appropriate ???SETPROPS() (or Erik's eView). Once the RVs are defined properly, their correct behavior and definition can be stored in the metadata of SDT and repaired if necessary, and in fact can be updated in place by creating a new set of metadata for updating the schema and using SDT's Update mechanism.