>SNIP
>>A good workaround, at least for the parametrized ones, is to supply an impossible value for the parameter in the makeview_{name here} routine, so at least it doesn't pull any records, even if it has to open.
>SNIP
>
>Dragan,
>
>PMFJI, but I do this in a couple of places and thought it was bad programming. I'm glad to see that it probably is not... :-)

I'm no source of gospel, but it it comforts you to have one think-alike... I've found at some point that the parameters better be defined, so then let them have some 'useful' value.

>I'm going to digest this part about making views in a separate database...sounds like something I need to understand.

Take what you have in the gendbc generated routine, and just insert a Create Database vw_dbc (or whatever name you choose, I usually prefix them with vw_) before the first MakeView_* call. Comment out the calls for MakeTable_* and the Create Database {original database} and insert Open Database {original database} instead. Save as a separate .prg (my naming convention is gen_vw*.prg) and run it. You can then drop all the views from the original database.

What you have now is the original database with tables only, and vw_dbc with views only. Now you can also pass its name as a parameter to this gen_Vwdbc.prg, so it basically becomes

Lparameters cVwDbc
Open Database {original database}
Create Database (cVwDbc)
MakeView_firstview()
MakeView_secondview()
...
MakeView_EnthView()

The reason I'm passing the name as a parameter is that the path in the name points to workstations own temp directory. That's it. If the structure of the original tables ever changes, or you want to do something else with these views, just edit this .prg and run it. You can edit any one of the views with EView, and replace the MakeView_n routine with the routine EView generates. Just so easy, and no headache. Never had a message "the structure of underlying tables...".