Odd behaviour with getMaxRecordIndex() and getSize()

Classic Servoy
1

I am trying to do a very simple calculation to find out how many lines in a tabpanel exist, and how many have ‘1’ in a field called received - so that I can calculate whether all lines have been received or not.

If I do

function foundcount()
{
return foundset.getMaxRecordIndex()
}

I get a different number depending on which line is selected. It is also not live, so if I remove some lines, it does not update. If I log out and back in to Servoy, it appears correct, but again is not a live number.

If I put a label on the form which contains

%%maxRecordIndex%%

, it works perfectly and is always the correct number and changes when lines are added and removed.

I am seeing this issue in Developer, and have not tried yet in client.

I have been struggling for 1 full day to find out why I can’t calculate the difference between how many related records there are and how many related records there are on a slightly different relation (where received also == ‘1’)

Servoy 5.2, Sybase 11, Mac Pro, Java 1.6,

Any help would be appreciated.

Thanks

Bevil

2

Bevel, why do you need the foundset count in a calculation??

remember, with every row you see, this calcuation is fired, and if it goes to the next 200 records, the foundsetcount is changed, but than also again for all records!
you will end up in trouble really soon!

why don’t you create an aggregate count, and ask than one, up in your calculation??

or do it in your mother form: relation_to_relation.getSize()

3

Hey Harjo

My lines never go more than 10 or 20.

Is it a bug that the numbers are not live? Or am I doing something wrong?

Happy to use an aggregate if that will work (on which field though? I don’t want to know the value of anything, just the number of records for this and the number of records where a value is set to 1 (so that would be an aggregate count I guess))

4

first of all:

return foundset.getMaxRecordIndex()

that “foundset” is a relation name right?
You dont try there the access the foundset where the calculation is in?
That shouldnt even work, and if it is thats by a big accident and i would see that as a bug…

harjo told you the right thing, use an aggregation for this. way way way better.

5

yes, create an aggregate count on just the pk for instance and than access that one from your mother form like this:

relation1_to_relation1.my_aggregation_count

and

relation2_to_relation2.my_aggregation_count

6

Okay, I will try that, thanks Harjo.

Is there a reason that what I was trying didn’t work? It is unclear why this doesn’t work, and isn’t live data?

7

Johan, can you explain it?

It know why, but find it hard to explain…

8

Hey Johan

I think I understand it now. The trouble is that it was semi working, just unpredictably. If I use the foundset (and there is an existing foundset - why can’t I use a foundset in a calculation?), it would show the correct number each time I logged into the system, but deteriorate as anything else is clicked…

Bevil

9

because the calculation doesnt know where to watch on.
But still are we talking here about a foundset where the calculation is in? yes or no?
Because thats just illegal, a calculation can only go deeper so access record data and relations through that record.
A calc shouldnt go back so try to access its parent foundset.