Latest CVS commits

If you've got this multiple times, sorry, but I thought I'd cover as many 
people as possible.

A new batch of changes have been committed to CVS. Aside from a few fixes, the 
main change is the start of transaction/record locking support. This is 
currently limimited to PostgreSQL, but should reach MySQL (with InnoDB) in 
due course.

Also, the .pot files and libtool have been removed. To generate a set of .pot 
files for translation, run:

make -f admin.kde3/Makefile.common package-messages


The manual has not been updated yet, so here is what gives.



A new block roperty has been added (appearing under the "Data" branch) called 
"Record locking" which currently has two settings, "None" and "Lock row on 
update". "None" is hopefully obvious:) "Lock row on update" causes rekall to 
do the following as soon as the user starts to make a change in a record 
(eg., types a new character into a text field or changes a choice control):

* starts a server transaction
* refetches the record from the database using "select .... for update"
* checks whether the record has changed compared to the values on display

If the "select ... for update" fails then presumably some other database 
client has locked the record. Rekall cancels the transaction, warns the user 
and leaves the unchanged. In effect, the user cannot update any values until 
the other client unlocks the record.

If "select ... for update" succeeds but the record has changed (presumably 
someone else has updated the record) then Rekall cancels the transaction, 
updates the displayed values, and warns the user. This leaves the user seeing 
the updated values and in a position to consider what to do next.

If "select ... for update" succeeds and the record has not changed then the 
record is now locked until the user saves the changes or cancels (hits 
escape). At that point the transaction is committed or rolled back as 
appropriate.

Since PostgreSQL (and most/all servers?) can only have one transaction per 
client connection, rekall checks for the situation where the user is part way 
through one record update (with the record locked) and then tries to start an 
update in another form which has record locking. In this case the second 
update will fail with a warning that a transaction is already in progress 
(and will be enhanced to report which form in due course).


Note that the issue of updating a control from a script (eg., a value is 
changed as soon as focus enters the row) has not (yet) been addressed. Also, 
I'm intending to add other locking modes (eg., lock while table, etc) at some 
time in the future (likely driven by user requests:)

Feedback on these changes invited:))



-- 
Regards
Mike

http://www.rekallrevealed.org
*THE* GPL/Open Source database front end for Linux and Windows.