I notice in your save (modify) procedures you don't do any explicit record locking. Is this because you're re-reading the record within the transaction frame and you're using HTransactionCommitted and it's therefore not necessary? There also doesn't appear to be any error checking for locks; is that not necessary either or have I missed something?
in the features of the current implementation (OpenSource and Commercial versions with HFSQL C/S or Classic) there is NO need to do any type of different programming for the isolation modes, in the MODIFY code.
Thats because: "The record used is locked in write mode until the transaction is validated or canceled".
Things become interesting when you READ or QUERY a file ...
You will see how we handle the different modes in Reports and Queries, starting with v1.13
* Just note, that with the introduction of support for MySQL (or MariaDB) we will include an INTERNAL transaction manager to HIDE the differences between the RDBMs and support the BEST features for every RDBMS engine.
Thanks Steven. When you say the Isolation mode is very important, what exactly do you mean? I understand what the different modes do but how does using one over the other impact on the programming? I've had a look at your code to modify records & can't see that you change anything for the different modes you currently support.
Sorry for the delay in answering your post, but we are preparing a new version and the Hospitality module and seems like we "forgot" your post ...
Yes, as you said in your post, everything is taken care by the transaction frame.
We don't use any type of explicit record locking in the project - we leave all locking (and the error handling) to the transaction frame - and this depends on the RDBMs. This way we don't have to worry about any compatibility issues (or non supported features) between HFSQL C/S and other RDBMs (like MySQL, SQL Server etc.)
Just note that for transactions and the HFSQL C/S engine the ISOLATION mode is also VERY important.
Take a look here: https://help.windev.com/en-US/?1000020926&name=HTransactionIsolation
The current alpha360 implementation supports hReadCommitted and hReadUncommitted.
We are doing some test so we can include support for hRepeatableRead in the future.
* There are a few places in the current implementation where editing (not adding or deleting) is done DIRECTLY by WX tables. Here we don't use transactions (or any kind of explicit locking) but since "editing" here CANNOT touch Primary or Foreign Keys the technique works OK.
In the future these places will be transformed to complete forms also.