Out of the VFP tools subdirectory there is a utility GenDbc
which create the source code needed to re-construct
the DBC including views. Sometimes if the DBC is large
GenDbc errors out. There is another program GenDbcX
that does the same thing. I believe you can find GenDbcX
in the UT files section.
-myron kirby-
================================================
>Myron,
>I can see the merit to your method. Is there anyway to extract the view definitions from (I presume), the DBC? Or do I have to open each in the View Designer and Show SQL?
>
>Also, in the View Designer it has a place to store a variety of other information:
>...the variables (and their types), used in Parameterized Views;
>...Field Validation - Rule, Message, Default Value; - how do I specify these in code?
>...Display - Format, Input Mask, Caption;
>...Data Mapping
>...Map field types to classes - which I don't understand yet.
>...Comment
>...Update Criteria - how do I specify this in code?
>...Miscellaneous - Cross Tabulate, Top - how do I specify this in code?
>
>I haven't seen in my books how you do this in code.
>I assume you're using "Create SQL View"
>
>Thank you.
>Rick
>
>>============================================
>>Each of my create views are in a PRG. Then I have a master
>>program that calls each of my view PRG's. I did the master
>>program because of the problem that you encountered. Also,
>>if you are not using Stonefield (www.Stonefield.com), I would
>>highly recommend it.
>>-myron kirby-
>>============================================
>>>Real life programming isn't dull...but sometimes....
>>>I'm about to deliver my app to the user and just found out yesterday that with each order a client places, some clients also submit a PO for THAT order, instead of using a blanket PO as the user identified earlier in the project. (in hindsight, I must have been blind to miss this myself...it only makes sense...)
>>>
>>>As a result I have had to modify the structure of my Orders table to include an order specific PO number (Orders.Order_PO).
>>>
>>>If I'm correct this means that each of my views which use Orders as a component now need to be "refreshed" to reflect the new field. (Not to mention the work on my forms and reports)
>>>
>>>Is there an easy way, and automated way, to keep my views in conformity with my tables? Am I worried about nothing? Aside from the fact that I should probably buy xCase and Stonefield, should I buy xCase and Stonefield, or something similar? And if so, what and why? Will any of these automatically update objects on forms, and reports, if I change the definition of the field the object is based on?
>>>
>>>Am I fretting over nothing? ... Or expecting too much from my delevopment environment...in wishing that a structure redefinition would be rippled through each form and report and view, in which it is relevant? ... kind of like class inheritance, but at the data dictionary level....