>James
>
>I got the gist that your grid holds values from more than on table, e.g. group ID from one table and the Group name and details from the Group look-up table.
>
>A view is essentially the resultant cursor of an SQL statement, looking across tables, and thus can be treated as a flat table in its own right, and can be the source to a grid. So you could dispense with these relationships (I'm not sure that can work too well in a grid anyway, and I've certainly never had such a set-up in a grid)
>
>Setting up a view is quite simple and intuitive via the View Designer (similar to the QBE grid in Excel)
>
>You MAY have a "yankee screwdriver" in your hand but you don't want a sledge for panel pins, or tack hammer for floorboard brads.
>
>Now then, I see you've only free tables and, yes, views can only be built on database tables.

Not true. Views can be built on free tables - it's the views themselves that need to be stored in a DBC. As you said, a view is just a cursor coming from a SQL statement, but if we want to use it over and over, the SQL statement (and a bunch of properties preset for the cursor) need to be stored somewhere, and the DBC is the place. Also, a view can pull data from several tables, with no limitation to where the tables are - they may be free, may belong to the same dbc, to another dbc, or may as well be views themselves. I've had views in one dbc which pulled data from two tables which belonged to two other dbc'es, no problem there.

That being said, we'd need just one dbc for the views, and can keep the tables free. Not that I'm starting any table liberation movement here :).