Compiere ERP + CRM Business Solution

We are moving all Open Support Requests, Bugs and Feature Requests to
Compiere Case Management. Please refer to the following link for
information on creating new Support Requests.
http://www.compiere.com/support/community.php

Thank you

I've seen that behavior (dead.letter kind of thing) under Unix only in
utilities like text editors, but never on ERP/CRM applications.

But on Windows you are probably right that during a regular shutdown of
the workstation the Compiere application should commit or ask what to do.

Both the database and the client are in the same box.
And when there's a regular shutdown of that workstation (not a crash), the
Compiere application neither commits the current record nor asks me what to
do.
Admittedly, this behaviour is normal under Unix but an externally
terminated programme usually restores lost data upon request (á la
dead.letter); it is unexpected on the Microsoft platform and Compiere does
not use the Unix convention either, it just drops what I entered.

In your scenario, are both, the database and the client in the same box?
And when there's a regular shutdown of that workstation (not a crash), the
problem that you are seeing is that the Compiere application is not
committing neither asking the user what to do?

My assumption is that if the workstation or the database crashes, then
there is no option and the uncommitted changes will be lost.

I believe the database is still up at that point because desktop
applications quit first.

I'm not sure I understand your scenario. If the database is already down,
there's nothing the Compiere application can do to commit the dirty records
and at that point, rolling back is the only valid option.

I do not think so. The database is a service and Compiere client is a
desktop application so it should quit first while the database connection
is still valid. When the current record is uncommitted (dirty), you have
the option of committing it quietly (as you do when the user moves to the
next record, closes the form or whatever) or asking the user what to do the
way Notepad does it (does not seem the right thing to me). Rolling back or
abandoning the changes is unacceptable.
Note also that in theory commissions can be performed in batches (this is
somewhat fragile but theoretically possible); under such settings the whole
latest batch would be lost.

If the database crashes or shuts down, any uncommitted changes should be
rolled back and you'd need to re-aenter the changes again in order to
preserve data consistency.

Could you clarify what exactly is the issue?