Logical problem with transactions and GUI-clients

Hi,

I do understand the reasons to use transactions and what they do.
My problem is the actual usage of transactions in a complex client
application.

Suppose there are tables:
customers (cus_id, name, notes, ...)
postal_adresses (pa_id, cust_id, street, zip, city, county)
electronic_addresses (ea_id, cust_id, e_adress, es_type)
// ea_type might be email, phone-, fax-number, www, ...
contacts (cust_id, contact_date, notes, ...)
... and some more that are foreign-keyd to customers

users create and edit those records in forms.

Where would I start the transaction?

1) On start of the application
A crash would trigger a rollback and kill every bit of work a user had
done probaply on the whole workday.
NOT GOOD

2) On opening the customer form.
Then anything that is done gets lost, when the transaction doesnt get
committed for some reasons on close of the customer-form.
This was sensible if the customer is new.
But let's say a user opens customer 42 and calls him up on the phone.
For this call the user appends a contact to make notes about the
conversation. ---> Contact-Form
The customer gave a new postal-adress. ---> PAddress-Form
Child-forms are closed and the user is back in the Customer-Form which
lay open while we had the detail-forms on top of it.
Then lightning strikes ---> CRASH so the Customer-Form didn't get committed.
The new contact and address is lost. The users wouldn't expect nor like
this behaviour either.

3) On opening of every Child-Form.
There might be an committed address even though the customer got rolled
back.
This would violate a referential integrity constraint.

Can someone point me the way to go, please ?