Processor Usage after building a related array

Panorama X Beta 10.2
1

Recently, the processor on my computer has been hitting around 100% on the processes being run by Panorama and just hanging there. The fans get to running very noticeably. Just moving a Panorama window ends up with a beachball for minutes at a time. Even as it sits untouched, Panorama continues to hang around the 100% mark, sometimes going slightly higher.

I finally tracked it down to a procedure that builds a related array, then processes it into a smaller array for a matrix. It takes an instant for the procedure to run and update the matrix, then it does nothing more.

The resulting array for the matrix is fairly small. Whether the matrix is displayed in an open form or not, once this procedure has run Panorama never seems to recover. I’ve even tried emptying the variable that contains the array for the matrix with no success.

All variables used to build the matrix array are locals so none of them should exist any longer.

Closing the database is the only resolution, even as others remain open. Re-opening the database does not run the processes back up unless I run the procedure to build that related array.

Since writing the above, I’ve determined that this is the line that seems to be the issue:

Let lvTransactions = relatedarray(cr(),{strip(TransType)+¬+datepattern(Date,“mm/dd/yy”)+¬+pattern(Amount,“#”)+¬+Client+¬+Account},“Receipts”)

There’s no obvious reason it should continue to influence Panorama’s usage of the processor. But after running solely this line, Panorama’s processor usage goes from negligible to 100% and just stays there until the database is closed.

Screenshot 2023-04-19 at 10.41.36 AM

2

I’m hoping there’s a way to resolve this. It’s an important matrix and the procedure updates it almost instantly. And then it should be done - especially since it’s a local variable doing the work.

Instead the program becomes unusable with minutes of beachballs in response to everything.

3

After a lot of poking around I seem to have mostly resolved it but not as one would expect. I ended the procedure with"
Undefine lvTransactions

Since this is s local variable, that shouldn’t make any difference. If it was a Global, it actually shouldn’t matter if it continued to exist with an array as its value.

Am I sure it’s a local? Yes, the View Search confirms that it exists no where else and the only time it’s assigned a value in the only procedure to use it is in the line I quoted earlier with "Let lvTransactions = "

With the Undefine added, the processor load is reduced to a normal level once the procedure has run.