>>I think the business need for adding a parent and a child at the same time to the same cursor is probably much rarer. I've never had a need to do it.
>
>Erik - what about the case where a line item may have additional line item information in a one-to-one if it is a line item of a certain type?
>
>Example - I sell widgets, things, and doomahickeys - all separate inventory codes for my line items. doomahickey line items have extra information that the other two don't need. Only a small portion of my business is doomahickeys so it is bad-magic (not to mention denormalized) to just add extra fields and null them for other types. I need a one-to-one in a cursor and both updateable.
>
>Stuff like this happens all the time. Surprised you haven't seen it.
>
>thanks,

Ken,
I agree with the design to break the extra fields out but this isn't an example of what I was saying. If the view were designed to update both tables and you appended a record to the parent table and it wasn't a doomahickey, then you would get an extra record in the doomahickey extra information table and not need one.

However, since you don't use views in this way, you wouldn't have to worry about this in the first place. You would just have conditional code in the AddUpdateDeleteInventoryItem SP that checked to see if the item was a doomahickey and if it was, insert a new record into the child table.