Jiwa

Hi Mike,

A while ago I made a post about what had been Large Transaction Mode in 6.5.13 that was here https://forums.jiwa.com.au/viewtopic.php?f=26&t=819 and I have follow the advice you gave in terms improving SQL performance.

Unfortunately this hasn't helped much, so I was wondering how much you know about SQL's in memory features under SQL 2016 and if there is anything that can be done using SQL 2016 that might help improve performance further as this is a database with transaction in it going back to 2003 and the only other idea I have had is to try archiving some of the debtor transaction and sales data?

SBarnes wrote:Hi Mike,

A while ago I made a post about what had been Large Transaction Mode in 6.5.13 that was here https://forums.jiwa.com.au/viewtopic.php?f=26&t=819 and I have follow the advice you gave in terms improving SQL performance.

Unfortunately this hasn't helped much, so I was wondering how much you know about SQL's in memory features under SQL 2016 and if there is anything that can be done using SQL 2016 that might help improve performance further as this is a database with transaction in it going back to 2003 and the only other idea I have had is to try archiving some of the debtor transaction and sales data?

Hi Stuart,

With a large number of rows, the bottleneck isn't the SQL Server, it's the grid control displaying all the rows of data. Paging (large transaction mode) would help with that, but you can't do that via plugin without some events being introduced by the forms for each grid display.

I've added improvement DEV-6356 to our backlog to consider how we'd manage paging on grids.

Mike

I spent a few hours looking at this after discovering the VirtualMode of the Farpoint Spread no longer exists in the .NET version (it did in the COM version Jiwa 6 had), and it's not exactly simple - but it looks possible, with some changes to our code within our JiwaGrid control (which inherits from the Farpoint Spread control), and also changes in each form for each grid where this would be beneficial.

Until we can do that, I'll tackle trying this entirely as a plugin - the idea being you hide the existing grid (or tab) and add a custom tab to the form with a grid to act as a replacement - 'tis an interesting challenge

Thanks.

I am over users who think data should load in an instant regardless of the amount of processing that has to be done or the volume involved.