Transactions & Portal navigation (Strange behaviour)

Classic Servoy
1

Hello, we found a very strange behaviour when using transaction while navigating from portal to corresponding formInDialog.
Servoy seems to loose the foundset to the portal as soon as the formInDialog is invoked with a transaction (see code examples below).
At that point we found a workaround by saving the foundset before and restoring it after the transaction ends (either commit or rollback).

Are you aware of this behaviour?

Details:
On the resource form, we have a portal to communications, by clicking on a button, we open a formInDialog to communication (code a).

(Code a)

forms.rCommunications.controller.loadRecords(rr_to_rc);
application.showFormInDialog(forms.rCommunications,200,200,440,150,'i18n:GLS.rResources.wTitle.Communications',false,false,false);

After having added transactions, the same code only points once to the correct related record, all subsequent calls opened the formInDialog, but showed the first record of the communications table, regardless of the line clicked in the portal, until we changed from one record to the other in the parent table (resources), or reloaded the found set:
(Code b)

forms.rCommunications.controller.loadRecords(rr_to_rc);
databaseManager.startTransaction()
application.showFormInDialog(forms.rCommunications,200,200,440,150,'i18n:GLS.rResources.wTitle.Communications',false,false,false);
var hasTransaction = databaseManager.hasTransaction();
if ( hasTransaction = true ) // no commit nor rollback was issued in dialog
{
	databaseManager.rollbackTransaction();
}

Finally, we found a workaround by writing:

forms.rCommunications.controller.loadRecords(rr_to_rc);
var theFoundset = currentcontroller.duplicateFoundSet();
databaseManager.startTransaction()
application.showFormInDialog(forms.rCommunications,200,200,440,150,'i18n:GLS.rResources.wTitle.Communications',false,false,false);
var hasTransaction = databaseManager.hasTransaction();
if ( hasTransaction = true ) // no commit nor rollback was issued in dialog
{
	databaseManager.rollbackTransaction();
}
currentcontroller.loadRecords(theFoundset);

The called form has separate foundset attribute on. Is this a bug or should we always save and restore foundsets when using transactions?

Have a nice day,

2

can i have that code in an (example) solution?
Does it matter if the rollback() was called or not?

i think what happes is that the related foundset in the portal is not the same anymore as the related foundset you then set in the dialog. Because of a flush..

That’s why when you set the (foundset) record back in the portal get’s a new relatedfoundset, which is again in sync with the record itself.

If you use Code B and before opening the dialog again. You first go to the next record and then back in the main form. Does this help youre problem also?

3

Thank you Johan,

I was not in office today, but I will create an example solution tomorrow if necessary…

Does it matter if the rollback() was called or not?

No, the behaviour is the same if I click on ‘Ok’ (=commit), ‘Cancel’ (=rollback), or if I hit the escape key which close dialog.

If you use Code B and before opening the dialog again. You first go to the next record and then back in the main form. Does this help youre problem also?

Sure, it works too using that method, but I prefer to restore a foundset, which I found more elegant. :wink:

Is this explanation sufficient, or should I build an example (our solution has a fairly complicated data structure) ?

Should transactions flush foundsets? Obviously I set the foundset before opening the transaction, as I didn’t want this foundset wiped by a rollback.

thank you in advance for your support.

4

i have already reproduced and fixed it for 2.1.1.
This is quite some internal change so we need some strong testing before we can release it.

5

:D

Many thanks, Johan !

I really appreciate your (and Servoy team) responsiveness.
Day after day we enjoy using Servoy.