>Your points are valid, Andrea. Each application and each situation within an app requires decisions that you have to be comfortable with. For myself, I've learned to do what you prefer not to do - use a grid (or listbox) to present the data in a tabular form, but not as a data-entry device. Even if you use the grid for data entry, you can present the "user friendly" fields (brought in via a join) in read-only columns.

Ah, but I'm not using the grid to enter data. I use it only to show the currently available records. Then I can double click a record and a new form appears letting me choose whether to browse only or modify the values. So the entire grid is read-only, and after all only the records of the main table involved in the view are updatable. Remember Outlook ? Very similar.
>
>Other constraints affect your decisions too. For instance, the app I'm working on now has to work C/S and with local data. Therefore the view syntax must be supported both by VFP and SQL/Server. This encourages keeping things simple, and living with the limitations *g*.

These are news ! I have exactly the same needs. My app will be installed both as a C/S app for NT networks with SQL Server and as a local version for small peer-to-peer ones. The current problems are with security problems for both modes (how could I check if the maximum number of connected users has been reached, for example). I think that we'll cross our messages again soon !! :-)