>Yes, I guess this is a good strategy. I had experimented with creating views programmatically, but this has two pitfalls: (1) the code is verbose after you've set all the attributes, (2) if you are thinking of doing a DROP VIEW before setting up the new view (to clear out an obsolete definition) someone else might be using it.

You don't need to DROP VIEW. Just run the code that defines the view again and the old definition will be written over. (You will be prompted depending on SET SAFETY. It doesn't matter if someone is using the view while you are redefining it, because when they initially USE it, it's definition is loaded into memory and the record is not locked.

If you maintain view definitions in code, you should check out my utilities here in the files section under 'gentable'. There are two programs, one for views, one for tables that do the same thing as gendbc, but for a single view or songle table. Passing genview a view name creates a prg that is a complete code definition of your view, including all update attributes. The result can be run on a different database to effectively 'copy' a view.