Ed's right. We use VFP7 with SQL Server 2000. I use SDT to manage fixing the remote views' metadata when a table changes, and eViews to manage other alterations to the view such as a where clause or the Fetchsize property. eViews is also great for generating a .prg that scripts every aspect of the view. I generate a prg for every view and store it in a directory. If a view gets corrupted, I simply run this prg to fix it. If a view needs to be fixed, I alter the prg. If a whole DBC blows out or I need to create a new DBC, I run a master prg which calls each of the RV prgs and recreates them. This combination is an extremely powerful and useful tool. You should definitely use them.

As far as creating a method to speed up views, try something like :

CREATE SQL VIEW lcViewName ;
REMOTE CONNECT lcConnectName ;
AS SELECT lcFieldSelection FROM lcTableSelected + ;
lcOptionalConditions

If you are going to go this route, I would suggest looking into SQL Pass Through to see if that will work better for you.

Pass to lcOptionalConditions a WHERE clause that would narrow the returned records down to a manageable size. You can include an ORDER BY statement if you want. You really should move away from selecting * from a table unless necessary. Not only does that bloat the returned data set, but every time you alter the structure of the table you are selecting from, you have to recreate every view that has a SELECT * from it. SDT will do this for you automatically if your tables are VFP tables, but not anything else. You will have to manually redefine the views within SDT, then use eViews to write a new prg for them.

HTH

-Justin

>>Thanks for the suggestions but all this needs to happen on the client's PC.
>
>Actually, it doesn't - make a copy of the client's DBC, and install it on your own system. Install SDT and register it's metadata on the developer's machine. Use eView to modify the RVs, run SDT's database explotrer, and freshen the metadata.
>
>Write a small app using the SDT runtimes that will run on the client site. Send this plus the updated metadata to the client site. Run the app against the client's DBC; and invoke the Update method - this will cause the DBC, tables, views and indexes on the client system to be brought into compliance with the metadata you've supplied with all the new view and index information. When it completes, the client's DBC will be functionally identical to yours because its structures have been updated via SDT.
>
>>
>>>>I was hoping for a simple method of opening the DBC and trapping the error so that the RVs can be automatically recreated. To recreate the RVs I use :
>>>>
>>>>CREATE SQL VIEW "XXXX" ;
>>>> REMOTE CONNECT "SQLCONN" SHARE ;
>>>> AS SELECT * FROM xxxx ;
>>>> WHERE xxxx.key IN(?goAPP.gnKEY)
>>>>
>>>>I was hoping for large tables I could limit the "SELECT * " to just one record.
>>>
>>>Download a copy of eView and buy SDT.