Hi João,

Are you performing a group by in the aggregate query?

Cheers,
Miguel

Hi Miguel,

Yes i am performing a group by.

João Gomes

The Max Records on the Aggregate shouldn't affect this count either...

I have also come across this, also having a group by. (Miguel/OutSystems: this is support case #880530)

me to, also in a group by!

I've got word from OutSystems that this issue will be solved in the upcoming platform release of 22 May.

Is this related to any specific version or is it affecting all version 9 releases?

Currently I am experiencing the same issue on Version 9.0.0.19.

We've experienced it on version 9.0.0.19, and it hasn't been solved yet, so assume all versions.

I'm experiencing the bug in version 9.0.0.23.
And since Kilian has an open support ticket, i don't think it has been solved yet.

Hi,

The issue should affect all 9 versions as the planned release is on end of May like Killian said.

I would just like to mention that the .Count property is only to be used for pagination purposes.
On other scenarios It's most likelly that what you want is actually the .Length property (that works correcty).
Some reports of this issue were in situations where the usage not correct.

Regards,
João Rosado

Just for the record, I'd like to say that we indeed encountered this issue when applying pagination to a table, and wouldn't dream of using the .Count for anything else (well, not if .Length can be used, that is) :).

"I would just like to mention that the .Count property is only to be used for pagination purposes."

I have to 100% disagree.

There are many times where .Count is the right thing to use. If you ONLY need the Count from the query, calling .Length will force it to actually retrieve all records, .Count will make it run a COUNT(*) which is far more efficient.

In fact, the only times in which .Legnth is the right choice, is when you've already (or will) pull all of the records anyways and are looping over them without restricting yourself to the portion of the record set to be displayed on screen (not using Start Index and Record Count).

Any other use of .Length is inefficient... again, the under-the-hood behavior is to actually retreive the records, push them into memory and then count the number of records.

Which is exactly why .Length is unaffected by the bug... because it isn't trying to figure out the SQL to write to convert your row selection to a COUNT(*).

J.Ja

Justin,

I think there is a detail missing, which is that the platform runs the query one time just to get the output .Count, meaning it will run it twice - one to give the output .List and another to give output .Count

So its more efficient to always use the Length unless if the query is really only used to Count (data not iterated). So, if you don't have any limit in your .Length use it instead of running the query a second time just to get .Count

Respect ;)

Tiago -

Like I said, only time to prefer .Length is if you are going to retreive all of the records anyways.

The majority of List-style screens do NOT retrieve all of the records by default. They retreive X records, where X is the LineCount of the List on the screen. If you are iterating in Preparation or on a table refresh, you should be limiting to the records displayed on the screen most of the time.

In the applications I've worked with, preferring .Count to .Length has been a critical part of making the application perform properly... as explained to us by OutSystems during an intense, month-long performance audit.

J.Ja

Hello guys,

Any news about this bug?

I'm still having problems with it.

Cheers,
Rafael Sousa

Hi Rafael,

It should be fixed in platform server 9.0.1.9 (released 22 May). So either you're not on that version, or you encounter something else.

I'm on 9.0.1.21

My problem is on the navigation of a table feeded by an aggregate with group bys.

First the count returned 1, then, after i changed the TotalRowCount from the list_counter widget to get the length instead of the count, the aggregate started to return the number of line count (from the table) plus 1 and never the right value.

Hi Rafael,

There is no platform server 9.0.1.21. The latest version is 9.0.1.25, the one before that was 9.0.1.19. 9.0.1.21 is a Service Studio version. Can you check in Service Center wat the version of the Platform Server is?

Ah ok, the platform server is still in the 9.0.0.2.

That's the problem right?

Thanks,
Rafael Sousa

Yes, that is the problem.

Hi,

I still encounter this issue on the current version. (9.0.1.40).


Thanks.

Hi Christopher,

Extraordinary claims requite extraordinary proof - can you share an eSpace? :)

Hi Kilian,

Please see attached file. Kindly help me on this one. The name of the Web Form is RequestSCRAList.


Thank you.

Best regards,

Christopher

Hi Christopher,

As far as I can see, everything looks good in the eSpace. What is your platform version? 9.0.1.40 is the Service Studio version, but that says nothing about the platform.