Hello,
A client recently created a GI and the system almost came to a standstill. When the process was stopped the performance was back to normal.
I seem to think that there was a post about things to avoid when designing a GI so that it does not drain too much of the CPU but cant find it.
Can anyone help?
Thanks
James
Best answer by laurabarber45
Hello,
Look at what tables are being used and how they are joined. Incorrect joins can cause many multiples of records to be generated by a GI. On any GI that is pulling transactions, I use conditions and parameters to avoid sending “all” transactions to the screen. For example, add a required parameter/filter so the customer must choose a period or an account when showing transaction-level detail.
I hope this helps you.
+17Hi
Does the GI have the OData selected? There were a few posts regarding that:
Why is OData $select parameter so slow? | Community (acumatica.com)
If not, what is the data you are trying to pull for the GI? It could be how the GI is written and what the system is trying to search for.
Thanks Kbeatty21
It is a GI executed within Acumatica. We are not pulling the data externally from PowerBi.
James
+19Hello,
Look at what tables are being used and how they are joined. Incorrect joins can cause many multiples of records to be generated by a GI. On any GI that is pulling transactions, I use conditions and parameters to avoid sending “all” transactions to the screen. For example, add a required parameter/filter so the customer must choose a period or an account when showing transaction-level detail.
I hope this helps you.
+11
I think a GI needs a "GO” button, because everytime you change a parameter (if more than one) it searches. Why net choose all your parameters and then click "GO”?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
