Great reply! Thanks.

I have a program that extracts out code from the GenDBC output by passing it a table name. It easily can by modified to handle multiple/all tables in the database. Can you think of a way using the database container that I could identify the base views for any dependent views, and determine the name/type of parameters needed so I could generate my update program automatically?

UPDATE: I think we came up with a way to handle this. Not the best, but part of the problem has to do with the order of the function calls that GenDBC generates. We rarely create new views anymore, so I can manually order the list and add appropriate public paramaters at the top of our upgrade program. This should allow my program to run through and not ask for tables to be opened or parameters to be populated. Finding it hard to understand why GenDBC does not already handle this though.

>I run gendbc to create a program to recreate this database and it creates the program with no problem. But when I run that program and it gets to the code that is recreating these views that are based on other views, I get the open dialog and it asks for parameters. All p-views based on only tables, are always created without interaction. But for a view which selects fields from another view, it has to open the base view with parameters which does not exist on disk and is not already open, therefore it pops up the open file dialog and asks for parameters to open the base view.
>
>You can modify the program generated by GENDBC so that it ALWAYS creates the base view before it creates the dependent view. Then in the MakeView_WhateverDependentView function code that creates the dependent view, if you provide dummy parameters and open the base view before the CREATE VIEW statement, you should be able to avoid the open dialog and parameters dialog because the base view is visible to the create view command. Unfortunately this has to be done each time you recreate the program using GenDBC, since it appears that GenDBC assumes that all views are created from tables on disk and doesn't create code to open a base view in this case.
>
>I know my explanation is a little hard to follow, but this is the only time I have seen what you describe. With over 500 views in the DBC and about 20 views based on other views, it took many hours to finally track down why this occurred and fix all occurances.
>
>HTH
>
>
>>Ran GenDBC on a clean production database. Put the resulting program in a new directory. Ran it. It displays the open table dialog dropdown. I also get the enter parameter dialog. This ocurred on one of the create view commands which used another view. I thought that it would recreate the entire database with no interaction. Why does this not work like I thought it should? Isn't that the whole idea of it?