>IMO (strictly):
>If your grid will utilize fields from two or more related tables, then it will work Ok initially until you will make it fancier. For example, if you will bring up some dialog, make changes in records and return back to the form containing grid, suddenly you can find that your grid forgot about relations (i.e. column from related table will show wrong values) and you have to set it programmatically again, this operation it its turn will evoke grid's flicker and you will have to play with Lockscreen. All of this is just 'minor' interface problems. However, more general reasoning is following: temp relationships will assume automatic moving of record pointers in all related tables. It was fine in old rosy dbase dos days, but now when so many things can be triggered (buffering, rules, defaults, etc.) by simple moving of a pointer, it's horrible perspective (strictly IMO).
>I prefer to use UDF-ed grid columns in situation when grid should show fields from Master+Lookups tables and, for some reason, I don't want to make cursor/view joins.

Hmmm... I'll have that very situation. I want to make it so you can double click on a row and a form will come up where you can modify the data in the record. If there's a chance it will lose the relation, I don't want that.

The thing I personally don't like about views is if someone is changing the information in the tables, you don't see it. I know you can do a requery, but if the view is nested, it doesn't requery the other views.

But losing the relations sounds like a nightmare. I guess I'll use views.

Thanks,