Glenn,

>What we need is a way to show the real status of each roll, but hold
>the permanent update until we save the order. My initial thought was
>to add a field to the roll transaction file. This field would be filled
>with something like "username". This record would be included in the
>roll status update...because it is a real record in the roll trans-
>action database. When the order is saved, the records for this roll,
>with this username in the new field would be deleted, and the update
>would proceed normally.

Does the "ROLLS OF CARPET FILE" have a field for quantity on hand (feet available), which starts with total length of roll and is updated by roll transactions?

If so, how about an extra field in the "ROLLS" file called "OnHold" that will be adjusted up or down as line items are added to or removed from the temp file? Your true available quantity would always be "OnHand" - "OnHold". As the line items are stored to the permanent file, the OnHold field would be reduced, and the amount permanently subtracted from the OnHand field.

If the temporary line item is deleted, or the transaction cancelled, you roll back the OnHold adjustments.

When you display roll status *during line item entry* show only the "Available quantity" (OnHand - OnHold), not all the details for that roll. You could have a Roll History routine elsewhere to show everything, but by omitting roll details during line item entry, you can simplify things considerably.

Now the gotchas:

1) Keeping a roll feet OnHand field perhaps violates strict normalization rules, but it's often done in accounting systems for things like customer balance due. You might need a re-sync routine to adjust transactions against OnHand if things ever get out of sync, due to system crashes, etc.

2) The same thing can happen with the OnHold field, but you could easily zero out that field periodically when no one is on the system (and clean out the temp file of any crash left-overs). When there are no temp transactions, all the OnHold fields should be zero, and can be easily reset without affecting the permanent OnHand field.

Just ideas, but that's the approach I would lean toward, unless I've missed some important details of your table structure.