Then maybe you should rethink about being against the grid. Grid is the simplest way to handle this IMHO.
Cetin

>Hi,
>
>I agree view isn't going to help in this case...
>Though your idea seems to need more coding but I can see the flexibility it offers.
>No offend, I got a feeling it will be hard to maintain in the long run, I mean not easy to recall after sometime.
>
>
>>>Hi,
>>>
>>>For tables that are linked by "one-to-many" relation, if I need to let user add and edit 1 record from the "one" table and multiple records from the "many" table, could it be possibly done by using a single view? Say the multiple means a fix N records, could it be possible to create a view when each time I add a record to the view, it adds 1 record in the parent table and N related records in the child table...
>>>
>>>Just in case, I can't use a grid for the "many" table because of presentation requirement.
>>
>>A view is unnecessary (maybe because I have never liked the view and don't use it). Simple solution would be a one-to-many form with a grid using relation. Since you don't want to use a grid then an alternative solution is to create an array of 'record' objects and bind form controls to those objects' properties. This would work very well especially in a case as yours where the child record count is fixed. Something like this:
>>
>>*new record - say 5 child records
>>

dimension thisform.aChild[5]
>>select ChildTable
>>for ix = 1 to 5
>>  scatter name thisform.aChild[m.ix] memo blank
>>endfor

>>
>>* Existing records
>>

select ChildTable
>>local ix
>>ix = 1
>>scan for fKeyParent = parent.Pkey and m.ix <= 5
>>  scatter name thisform.aChild[m.ix] memo
>>  ix = m.ix + 1
>>endscan

>>
>>A form control say using 3rd child record, dStart field:
>>
>>

.ControlSource = 'thisform.aChild[3].dStart'

>>
>>
>>You would use insert and gather to commit the children records. It is pretty easy and works wonderfully (have been using a similar case for years).
>>Cetin