>>>Hi everybody,
>>>I think, this question is pretty basic, but I hadn't experience with it so far.
>>>I want to create three tables:

>>>CustomerSpecific:
>>>    CustomerID ImportantLender WhatKindOfReport etc.
>>>       |
>>>    Regions table
>>>    CustomerID RegionID RegionName etc
>>>           |
>>>           RegionsSpecific
>>>           RegionID Town TownName

>>>
>>>The user should be able to pick a customer from customer table (with probably additional functionality to add new customers), then fill some specific info about customer criteria - one record in the first table, then he/she should be able to create region groups, e.g. assign a name for each group and associate towns with each region group (ever using Mover ListBox or multiselect Grid - I haven't decided yet).

---

>>For the first time you do that you can use something like:
>>

Select Regions.RegionID as RegionID, Cities.Town, Cities.TownName;
>>   from Cities;
>>   where Cities.Selected;
>>   into cursor myCursor

>>Of course you need a selected field then in your multiselect grid.
>>Tot create the edit view where you see the original items selected and where you can select others you may try this:
>>

Select Cities.Town, Cities.TownName, .f. as selected;
>>   from Cities;
>>   where Cities.Town not in;
>>   (select RegionSpecific.Town from RegionSpecific);
>>   union;
>>   Select RegionSpecific.town,RegionSpecific.TownName,.T.;
>>   from RegionSpecific;
>>   order by Town

>Hi Ko,
>
>Actually, my question was about form design and how should I organize the type of interface I have in mind. Suppose, I create a view. Now, how should I allow new configuration? E.g. 1) Select customer and fill related info, then create Region entries (IOW, CustomerID should be automatically assigned to the selected customer, if it's changed, it should be changed in regions table also). Finally, each region should allow to select towns, and RegionCode in TownSpecific table should be automatically set correctly. This is my problem. Is it feassable with a view or should I use three tables instead?
>
>Thanks.

---

:o
Sorry for not directly understanding what you meant.
I think you need 3 tables here like you said to store the data.
The customer info can be written directly in the underlying table.
When it changes you can use a replace all command, to replace all the customer id fields in the second table.
You also can assign an uniqueID to the customer table. Then you can use that UniqueID for the RI. when you then change the customerID you don't need to change the rest of the data.
The regions table can also be directly on the form, in a grid or something. The user doesn't need to select anything, but only can define new regions, or edit the regions he already had assigned to the customer.
The third table (with the Towns) can be a view. With the code above you can make a multiselect grid of that where the old selection is restored and where the user can simply select new towns, or deselect old towns.

In this case you have some textboxes for the customer info, a grid for the regions with add/remove capacity, and a multiselect grid for the towns.