Skip to main content

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

 

@jmorgan if you have a specific GI that is problematic, feel free to export it and attach it here for review

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.

Hi @jmorgan 

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 Laura,

That is useful

 

James

 

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”?

Thanks Kbeatty21

It is a GI executed within Acumatica.  We are not pulling the data externally from PowerBi.

James

Reply


Terms & ConditionsCookie settings