Hi

It is a [Bugtracker, bug 2511, fixed] Java tAggregateSortedRow forgets keys. but the bug isn't fixed yet.
To solve this issue, you can add a null row as the last row in your input data to get the right result.

Best regards

          shong

Hi Sean

Should I use a NULL row file and use tUnite anytime I want to use this object? Will it cause any unintended issues?

Currently, tAggregateSortedRow always ignore the  last groupin(of course, it is a bug and we will fix it). So now, if you want to use this componennt to get a right result, you should add a null row as the last row.

Best regards

           shong

plegall:

I tried to use a NULL file combined with tUnite. It did not work. May be because I am not sure what a NULL row is in a flat file context. Also the Word doc in one of the bug trackers was difficult for me to follow (probably due to my newbie status with TOS).

In any case, tASR makes sense if the tSort is much better at sorting files than aggregate component (at this time I do not have any DB inputs but just excel and flat files). Else just regular aggregate can do the same job of Sort + tASR.

I am from Informatica world where SORT component is very good compared to AGGREGATE and as such tend to use SORT and mark the AGGREGATE as "Sorted Input" which is same as using tASR.

If the bugtracker on this is closed, I think it should be opened, right?

Thank you for your help here and with other issues.

Regards,
Sean

Vaiko wrote:

I just run into this issue. Do you have any feedback for which release you are planning the fix?

As you can read in [Bugtracker, bug 2511, fixed] Java tAggregateSortedRow forgets keys, slanglois has added the solution I suggested, ie a new property "expected number of rows". He has commited his code a very short time ago and the solution will be available in next milestone (not in next main release, not in 2.3.2 but in 2.4.0M1). The solution was implemented only for the Java component, not the Perl component yet.

This solution is not a smart solution, but we currently have no other smarter solution. Any suggestion is welcomed.

Good morning, gentlement from the past.

I come from 2012 where we have TOS 5.0.1 to let you know that these promises are empty and this incredibly simple bug still hasn't been fixed.

There are simple ways to work around it by using tAggregateRow and, for cases of selection aggregate functions such as "first" or "max", you can use tSortRow with tUniqRow, so there's nothing vital about this component.

It is, however, a shameful blunder to keep such a harmful bug available to the uninformed user. My co-worker lost a week fruitlessly on this thinking her selects were wrong, and I lost two days until I got suspicious of the component.