Hi,
For this huge amount of data, do you really need a TGV?
What is the practical use case where users can still interact with a TGV in a meaningful way when it contains 1 million items? Is there anything useful they can do with the TGV besides exporting the data to Excel?
My questions are not intended to be provocative. I' m simply asking because, in most cases, a SQL query can solve the task much more efficiently than a TGV.
I had a more or less similiar use case too solve some time ago. The amount of data was much smaller than yours, but the query was very complex and needed very long to render the TGV. I ended up using a SQL query and rendered the result in a "treegrid-like" view.
Best regards
Angela
Thanks again Angela for the reply so finally I tried an alternative to the SQL-based approach, I prototyped an AML-based path: a custom server method that replicates the Query Definition logic, plus a new TypeScript module in CodeTree providing a metadata-table template and a scoped TreeGrid.ts. The goal was to bypass the stock Aras rb_GetTreeGridData functionality.
However, this approach carries meaningful risk. Replicating stock behavior means we have to re-implement concerns that Aras handles for us — security/permission enforcement being the main one — and get them exactly right. It also hurts maintainability: because it effectively replaces an existing Query Definition with hand-written code, every future change (adding a relationship or a property) would require editing CodeTree files rather than simply updating the QD.
Given that trade-off, I consider replacing the existing QD too risky to pursue as the primary solution.
