Be careful what views you open with MODIFY VIEW, or more precisely, what views you save once you've opened the View Designer. It can't handle any but the simplest views. In particular, the View Designer has problems with table relationships that involve what we like to call "unrelated siblings;" that is, tables that are both children of the same parent but do not have an inherent relationship. (For example, the TasTrade Orders table can be seen as parent to both the Customer and Shipper tables. But customer and shipper have no relationship.) In addition, if you've written a view by hand, there's a good chance the View Designer can't parse it correctly. When you open a view beyond its abilities, it makes it up as it goes. If you save the nonsense the View Designer comes up with, your view will be damaged. One basic rule—if you open a view with the View Designer and it looks funny, press ESC and get out without saving.

If you rename a view and other views are based on that view, the dependent views won't work anymore. You can't even open them up in the View Designer to fix the problem without losing the definition. You can fix things up by using DBSetProp() to gather and store all the relevant properties, and then redefine the view. The big problem, of course, is knowing that you have views dependent on a renamed view.

Modifying a view changes the current work area. While this is easily worked around, it can bite you if you're not expecting it.