David,

>I suppose it may depend on the approach you're taking with it.

my approach is to use grids for both master and detail table.

It is a quick way to build a data entry form, but this approach ... splits
the atom ! :)

>You might want to pursue it on the IBO list.

I already did it, but it is not an IBO problem, it is an architectural
problem :)

Data in grids is loose-coupled. Every row can be individually saved.

With IBO, there is a way to cache changes and apply them all together, but
I haven't fully investigated it.

I guess that it would be a drag for the user to keep control of "post",
"commit" and also "apply changes" buttons.

People have been killed for much less :)

>You could also arrange the database security so that only a particular
>stored procedure has the required permissions to delete from the
>detail table. That procedure would make any necessary checks before
>doing the actual deletion.

this is surely an interesting idea.

Also the reverse would work: let a particular stored procedure
insert/update data. You pass the procedure the whole master-detail record
and it does everything.

But ... I should say goodbye to my quick and dirt solution and re-write
(again!) my data entry forms.

This is something I won't do even if I find a horse head in my bed one of
these mornings :)

>The other consideration is to ask yourself why you need one or more
>detail rows instead of zero or more. It might be because you have
>things in the header that should be in a detail row or vice versa.

it is just a matter of error management.

You don't want to let the user be able to insert an invoice head and forget
to insert the relative rows.

>E poi avrai la possibilita' di dormire? ;-)

si' e anche di mangiare (finche' non consegno, non mi pagano...) :)

Ciao

Duilio