>>>>
>>>>Just as a .02 worth for others tracking this thread, I don't use any SET RELATIONS either. I do the same as you here with parameterized views throughout.
>>>>
>>>>Steve
>>>
>>>
>>>Steve,
>>>
>>>Do not know whether this is related or not but do you not find it akward to have to rely on the DBC when you want to change a view. Would that not be easier is every thing would be contained in the source prg, you would call it your client, and I call it the DE, but what is in a name :).
>>>
>>>Marc.
>>
>>I don't use the view designer at all. All of my view definitions are in a prg which I can update and run whenever I need to. I don't find that awkward in that the views I do put in the DBC are relatively fixed in nature. Sure, they might change, but not significantly. But I also have views that are really just cursors (not created using the CREATE command and not stored in the DBC), that have their code stored in "Client" or wherever needed.
>>
>>Steve
>
>Steve,
>
>How are they created then, excuse me for my ignorance. And is there a way to create your on (updateable) fields on the fly with a view. Excuse my ignorance again. And can you recompile your project while other are using the database in production? Well if you can, I might drop my reservations ... :)
>
>Thanks,
>
>Marc

They are stored to the DBC and available for use. I just run the prg containing the definitions. This prg is not even part of the application and is maintained separately. I don't use the designer....typically because there are views that I use that the designer simply cannot handle because of their complexity. But they are coded in an outside prg much like what GENDBC would create. I use create sql view followed by all the necessary =dbsetprop() calls, including those required to make them updatable. If one did need to create a view from within an app, each user would need a local copy of the dbc as it needs to be opened exclusive to write to it. And if you have a view but need it updatable in the app, you can always use cursorsetprop().

Steve