Recently I had some problems with a method (see posting Really strange behaviour - Classic Servoy - Servoy Community) and I finally found the guilty: setSelectedIndex() doesn’t permit to set as current record a record outside of the ones retrieved from the database.
I know Servoy retrieves records from the backend in batches of 200 for a lot of good reasons, but if I want to jump directly to setSelectedIndex(350) I should be able to do it, instead it simply doesn’t work.
I know that maybe some of you consider this a feature instead of a bug but in some circustances it’s really a bad feature, you can’t always know how much records are been retrieved at a certain point in time.
The correct behaviour should be, imho, that if I want to jump to 350 Servoy should retrieve the batch that contains Index(350).
In the other posting I was working on a record from table A, started a transaction on table B, rollback the transaction on table B and found that my table A current record was changed and that i couldn’t change it back because it was over the 200 records limit and setSelectedIndex() didn’t work.
This simple global method illustrates the bug very well, try to launch it as soon as you open a solution on a table with more than 200 records, if you try to jump to a setSelectedIndex()>200 it simply doesn’t work.
var index = plugins.dialogs.showInputDialog('Select the index to jump to','Index=');
currentcontroller.setSelectedIndex(index)
Correct me if I am wrong, feature or bug is not the question I think. What I wonder is why you want to jump to a record in a foundset via the index when it is outside of your foundset. Imho you would only want to jump to a record this way when you already know the index/content and can be sure to catch the wanted record.
In other words, jumping to a record with index 350 when it is outside your foundset is, again imho, the wrong road to go.
IT2BE:
Correct me if I am wrong, feature or bug is not the question I think. What I wonder is why you want to jump to a record in a foundset via the index when it is outside of your foundset. Imho you would only want to jump to a record this way when you already know the index/content and can be sure to catch the wanted record.
In other words, jumping to a record with index 350 when it is outside your foundset is, again imho, the wrong road to go.
Sorry, maybe I wasn’t clear enough.
This post originated from another post, to be brief I have a method launched from a form based on Table A that creates a bunch of records in another table B, since I want to use that table as a temporary table I wrapped the record creation process in a transaction following these flow:
Form based on Table A (record index=350)
Method:
<start transaction>
record creation on table B
printing of records of table B
<transation rollback>
Form based on table A (record index not changed)
At the transation rollback the records created are deleted from the table, this way I don’t have to bother about other users working on that table and all the rest: everything is finalazed to print some stuff, when it’s done the records used from the table are cleaned by the rollback.
In my opinion this was the clever way to accomplish my goal.
The problem is that if my current table A record is index=350 at the transation rollback Servoy reloads the first batch of records in table A (1-200) and switches my current table A record to index=200.
I can’t understand why Servoy needs to reload table A records from the backend since I’m wrapping in the transation only table B operations.
This alone is a BUG for me.
That said I decided to store my current table A record index at method start so that after the transation rollback I could get back to the correct record and again this doesn’t work.
This is why I need to jump to an index outside of the record batch loaded and I think there could be a lot of other situation where such a feature would be helpful.
can’t understand why Servoy needs to reload table A records from the backend since I’m wrapping in the transation only table B operations.
This alone is a BUG for me.
I agree…
But why don’t you store the pk instead of the index and search for that…
can’t understand why Servoy needs to reload table A records from the backend since I’m wrapping in the transation only table B operations.
This alone is a BUG for me.
I agree…
But why don’t you store the pk instead of the index and search for that…
Yep, I’m forced to store the foundset in a var, the PK in another var and restore both after the method completion but it’s not a nice way of doing things so I filed the bug report.