>The reasons I don't want to use a view:
>1. This is for a PickList class. The # of records could conceivable reach the
>millions depending on what tables are used.
>Since I want each column to be attached to an index, a view COULD take quite a
>bit of time to do the initial Query and Indexing. If a view could retain the
>indexes when it's not in use (like a table) then it would indeed be the ideal
>solution. Even assuming that I left the view open (which is not what I want
>to do), when a record is added/changed in the underlying tables a Requery()
>would have to be done in order to select another record to work with.
>
>2. In a grid when there are 2 child records for a parent record, the second
>line of the field showing the parent info contains "***********" instead of
>reprinting the parent info. If I did a view that contained a record for each
>parent-child combination, then each field would have info in it instead of
>"*****************".
>
>
>As for the relations/skip:
>I understand what relations and skip accomplish.
>I did determine that I really don't need the 1st set skip.

>          select table3
>          set order
>          select table2
>          set relation into table3
>          set order
>          select table1
>          set relation into table2
>          set skip to table2, table3

>
>If both the address and e-mail tables are set up in relations as you suggest, then address#1 is always on the same grid line as e-mail#1
>and address#2 is always on the same grid line as e-mail#2.
>There would be no way to select the address#2/e-mail#1 combination.
>(Granted in this particular example that wouldn't make any difference, but that
>doesn't mean that in some other set of tables that it wouldn't.)
>Doing it my way creates 4 grid lines:

>        Client  address#1  e-mail#1
>        Client  address#1  e-mail#2
>        Client  address#2  e-mail#1
>        Client  address#2  e-mail#2

>and because I'm useing related tables instead of a single view it actually looks
>like this:

>        Client  address#1  e-mail#1
>        ******  *********  e-mail#2
>        ******  address#2  e-mail#1
>        ******  *********  e-mail#2
>   or like this:
>        Client  address#1  e-mail#1
>        ******  address#2  ********
>        ******  address#1  e-mail#2
>        ******  address#2  ********

>depending on which column the cursor is sitting in.
>
>
>
>
>If you see something wrong with my reasoning, I would greatly appreciate a
>response.
>Comments are always welcome.
>
>Bill
>

Generally, temp relationships bring more harm than help. Actually, you hit the first problem only, which is resolvable. However, using this approach you could get more problems when making even simple grid refreshing. Sometimes, you will be requeried to use Form.Lockscreen, sometimes, you will even have to rebuild SET RELATION. So, it might be a good idea to use view/cursors. I understand your point, that view of millions records is not practical, but grid with millions of records is not practical either. Maybe you could change your interface, adding e.g. first-letter-pick combo, or something else to squeeze quantity of records to reasonable numbers. Also, you could use approach with one table grid and button-invoked dialogs.