Warning on sub-report sort performance
We use a modified invoice (and credit note) template that sorts line items by patient/date/productType/product name
Because the getDataSource function used to grab the data for the subreport can only sort of field names and not expressions, and because I needed to sort on date (rather than startTime), I did the necessary sort in iReports in the line item sub-report.
However, I left in the original getDataSource call - and hence I was functionally doing two sorts, one in the getDataSource call and one in the sub-report.
Last week as result of a 'do all my dogs' visit to a customer who had 8, a 40 item invoice was generated. This took around 70 seconds to print.
After investigating, I realised that I was doing two sorts. I altered the getDataSouce call to omit the sort argument. This dropped the print time to around 18 seconds - not dynamite but better than 70.
Conclusion1: I suspect that it is always better to sort in the subreport than use the getDataSource function to sort for you.
Conclusion2: as part of the investigation I looked at the performance of an SQL based report (ie one launched from 'Reporting|Reports' - it can generate the same output in around 3 seconds. This underlines the fact that we really need to do some work on the openvpms: functions to improve their performance. [It might be easier to provide a facility to invoke an sql datasourced report - the reports themselves are more difficult to code (for example the sql to do the equivalent of 'getBillingAddress' is not simple) but they run like the clappers.]
Regards, Tim G
Re: Warning on sub-report sort performance
I think SQL reports lack any Openvpms function ability whatsoever...you would be calling practice details, vet details, this list goes on.
I think maintaining object level datasource is really important and to be fair Tim A has stated on numerous occasssions that code optimization has not really been a upgrade feature of Open.
Re: Warning on sub-report sort performance
Ben - I agree that SQL is a pig to do some things (eg getBillingAddess, and I gave up trying to do getAccountBalance in an efficient manner and just summed all the tranactions), but it does go like the clappers.
At some point in time we are going to have look at the efficiency of the openvpms: functions. It p's me off that my son can bitch that RxWorks performs better than OpenVPMS - and he is correct in that for all its short comings, with RxWorks you really can pound in transactions.
Regards, Tim G