Sergey Berezniker recently pointed me out to it. I added it to my Tools menu...

>Hi!
>
>Thanks! I did not knew about it...
>
>>Hi Vlad,
>>
>>There is a utility in Download section here, written by Erik Moore, which produces a View or Table definition (e.g. you pass name of the view or name of the table). Very handy!
>>
>>>Hi!
>>>
>>>You do not need to write such a PRG. Look to GenDBC tool. It takes database and generates a PRG file for re-creating it completely. Produced by this tool PRG contains the entire code to re-create all views. You can then strip out that part, modify it and run to re-create only views in your database with required modifications. This is the simplest approach.
>>>
>>>With approach I described (table), you can find a code in GenDBC.PRG that strips out the view definitions and instead of saving these options as string into output PRG file, save them as text fields in some table. Then run this modified GenDBC to copy all information about views into table.
>>>
>>>To re-create views, you require to create a code like GenDBC creates for views.
>>>
>>>HTH.
>>>
>>>>Vlad,
>>>>
>>>>Thanks for the response!
>>>>
>>>>This sounds like it would be a great tool that would give you quite a bit of control over the data. The only issue I would have is inputing the view data into the table. Did you do this manually or did you write a prg that would do it automatically?
>>>>
>>>>Thanks!
>>>>
>>>>-Justin
>>>>
>>>>>Hi!
>>>>>
>>>>>We made for this purpose a special table that holds all SELECT stameents and properties for every view. Then we just run a program to re-create all views. Searching for certain table and alter queries now becomes much easier. Also, you can create this way views that could not be created normally by view designer because special query string.
>>>>>
>>>>>>Hello,
>>>>>>
>>>>>>Currently we are using a VFP7 front to our SQL Server 2000 back end. Our application updates the SQL Data through FoxPro remote views stored in a corresponding VFP database.
>>>>>>
>>>>>>Before we switched to a SQL back end, we used Stonefield to update all of our views dynamically whenever we changed the structure of a VFP table (ie adding a field). That no longer works with SQL data. We still use Stonefield, but in a much more laborious way; We now have to open the DBC, scroll through every view (over 500) for a reference to the altered table and redefine it. We then use eViews to generate a script for the view, then run that script for all of our DBs (about 15).
>>>>>>
>>>>>>There has got to be a better way of doing this. Does anyone know of a product that can automatically find and fix VFP remote views in a VFP DBC whenever the corresponding SQL DB has a table alteration?
>>>>>>
>>>>>>Your help is VERY appreciated.
>>>>>>
>>>>>>-Justin