Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Steve,

I have always believed these hidden range names originate from clients who have also used the OneStream Excel add-in on the same workbooks that they use with Planning Analytics.  It may not still happen and maybe the OneStream add-in does not generate all these hidden names anymore, but it did at a client with workbooks that were created prior to 2023 that were then just updated monthly using OneStream and PA add-ins, back and forth.

I remember one workbook that had over 100,000 hidden names. I found the easiest way to clean it was to unzip the Excel file, and manually delete a huge section from the workbook.xml component using Notepad++. I deleted a section that corresponded to the 100,000 hidden named ranges. Needless to say, that probably broke whatever OneStream WAS doing in the workbook, but the workbooks behaved much better with PAfE afterwards. The client no longer used OneStream, so it was a welcome exorcism. Using VBA to clean the Excel file was just too slow.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

We have the same exact issue and had to build a small webpage using python/streamlit that allows a user to upload the file with hidden named ranges and then clears them and returns a clean version to the user. All users we work with have no idea where they have come from and when hidden they aren't even aware they exist.

Steve,

I have always believed these hidden range names originate from clients who have also used the OneStream Excel add-in on the same workbooks that they use with Planning Analytics.  It may not still happen and maybe the OneStream add-in does not generate all these hidden names anymore, but it did at a client with workbooks that were created prior to 2023 that were then just updated monthly using OneStream and PA add-ins, back and forth.

I remember one workbook that had over 100,000 hidden names. I found the easiest way to clean it was to unzip the Excel file, and manually delete a huge section from the workbook.xml component using Notepad++. I deleted a section that corresponded to the 100,000 hidden named ranges. Needless to say, that probably broke whatever OneStream WAS doing in the workbook, but the workbooks behaved much better with PAfE afterwards. The client no longer used OneStream, so it was a welcome exorcism. Using VBA to clean the Excel file was just too slow.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

We have the same exact issue and had to build a small webpage using python/streamlit that allows a user to upload the file with hidden named ranges and then clears them and returns a clean version to the user. All users we work with have no idea where they have come from and when hidden they aren't even aware they exist.

Steve,

I have always believed these hidden range names originate from clients who have also used the OneStream Excel add-in on the same workbooks that they use with Planning Analytics.  It may not still happen and maybe the OneStream add-in does not generate all these hidden names anymore, but it did at a client with workbooks that were created prior to 2023 that were then just updated monthly using OneStream and PA add-ins, back and forth.

I remember one workbook that had over 100,000 hidden names. I found the easiest way to clean it was to unzip the Excel file, and manually delete a huge section from the workbook.xml component using Notepad++. I deleted a section that corresponded to the 100,000 hidden named ranges. Needless to say, that probably broke whatever OneStream WAS doing in the workbook, but the workbooks behaved much better with PAfE afterwards. The client no longer used OneStream, so it was a welcome exorcism. Using VBA to clean the Excel file was just too slow.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

We have the same exact issue and had to build a small webpage using python/streamlit that allows a user to upload the file with hidden named ranges and then clears them and returns a clean version to the user. All users we work with have no idea where they have come from and when hidden they aren't even aware they exist.

Steve,

I have always believed these hidden range names originate from clients who have also used the OneStream Excel add-in on the same workbooks that they use with Planning Analytics.  It may not still happen and maybe the OneStream add-in does not generate all these hidden names anymore, but it did at a client with workbooks that were created prior to 2023 that were then just updated monthly using OneStream and PA add-ins, back and forth.

I remember one workbook that had over 100,000 hidden names. I found the easiest way to clean it was to unzip the Excel file, and manually delete a huge section from the workbook.xml component using Notepad++. I deleted a section that corresponded to the 100,000 hidden named ranges. Needless to say, that probably broke whatever OneStream WAS doing in the workbook, but the workbooks behaved much better with PAfE afterwards. The client no longer used OneStream, so it was a welcome exorcism. Using VBA to clean the Excel file was just too slow.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi, 

Just out of curiosity: Are you using openpyxl in that context, or...?

We recently also ran into this issue again.

I tested openpyxl to remove all hidden names, but unfortunately it does not support all Excel features. For example, Excel shapes are lost in the process.
I also considered pywin32 and xlwings, but both rely on Excel under the hood, meaning you could run into Excel limitations again.

I am currently using and testing a Python script that removes all hidden names directly from the underlying workbook.xml.
Based on the limited testing performed so far, the results look good, and I have not encountered any Excel errors such as "We found a problem with some content... Do you want us to recover as much as we can?" when opening the file.

Just sharing my experience...

We have the same exact issue and had to build a small webpage using python/streamlit that allows a user to upload the file with hidden named ranges and then clears them and returns a clean version to the user. All users we work with have no idea where they have come from and when hidden they aren't even aware they exist.

Steve,

I have always believed these hidden range names originate from clients who have also used the OneStream Excel add-in on the same workbooks that they use with Planning Analytics.  It may not still happen and maybe the OneStream add-in does not generate all these hidden names anymore, but it did at a client with workbooks that were created prior to 2023 that were then just updated monthly using OneStream and PA add-ins, back and forth.

I remember one workbook that had over 100,000 hidden names. I found the easiest way to clean it was to unzip the Excel file, and manually delete a huge section from the workbook.xml component using Notepad++. I deleted a section that corresponded to the 100,000 hidden named ranges. Needless to say, that probably broke whatever OneStream WAS doing in the workbook, but the workbooks behaved much better with PAfE afterwards. The client no longer used OneStream, so it was a welcome exorcism. Using VBA to clean the Excel file was just too slow.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi, 

Just out of curiosity: Are you using openpyxl in that context, or...?

We recently also ran into this issue again.

I tested openpyxl to remove all hidden names, but unfortunately it does not support all Excel features. For example, Excel shapes are lost in the process.
I also considered pywin32 and xlwings, but both rely on Excel under the hood, meaning you could run into Excel limitations again.

I am currently using and testing a Python script that removes all hidden names directly from the underlying workbook.xml.
Based on the limited testing performed so far, the results look good, and I have not encountered any Excel errors such as "We found a problem with some content... Do you want us to recover as much as we can?" when opening the file.

Just sharing my experience...

We have the same exact issue and had to build a small webpage using python/streamlit that allows a user to upload the file with hidden named ranges and then clears them and returns a clean version to the user. All users we work with have no idea where they have come from and when hidden they aren't even aware they exist.

Steve,

I have always believed these hidden range names originate from clients who have also used the OneStream Excel add-in on the same workbooks that they use with Planning Analytics.  It may not still happen and maybe the OneStream add-in does not generate all these hidden names anymore, but it did at a client with workbooks that were created prior to 2023 that were then just updated monthly using OneStream and PA add-ins, back and forth.

I remember one workbook that had over 100,000 hidden names. I found the easiest way to clean it was to unzip the Excel file, and manually delete a huge section from the workbook.xml component using Notepad++. I deleted a section that corresponded to the 100,000 hidden named ranges. Needless to say, that probably broke whatever OneStream WAS doing in the workbook, but the workbooks behaved much better with PAfE afterwards. The client no longer used OneStream, so it was a welcome exorcism. Using VBA to clean the Excel file was just too slow.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

+1 to that. Because Perspectives was not impacted by hidden name ranges, at least not as significant as PAfE. 

Users are complaining that the performance of the new tool (PAfE) has downgraded. It will be interesting to see what's IBM take on this.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

You're a very convincing group 😊, and you're not wrong.

You're absolutely correct that PAfE can end up taking the reputational hit for issues that originate well outside of its control. When something goes wrong in Excel, the add‑in is often the first thing blamed… even when Excel itself has been quietly collecting named ranges like it's a hobby.

While this isn't strictly an IBM‑created problem, it is very much our shared problem, and we agree that ignoring it doesn't help anyone.

Given the feedback in this thread, we are prepared to look into the idea of a startup warning when a workbook is opened. The goal would be to clearly indicate that the workbook may be "dirty," including surfacing the number of named ranges it contains. Triggering this once on open (instead of repeatedly during normal operations) would at least give users a fighting chance to manage the situation proactively , before Excel brings the party to a halt.

In parallel, we'll also explore whether we can contribute to an open‑source, non‑IBM‑supported utility (likely Python‑based) that helps clean up these workbooks.

No promises yet, but the feedback here is well‑reasoned, and hard to ignore. Keep it coming, just maybe don't add any more named ranges while we're talking

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

You're a very convincing group 😊, and you're not wrong.

You're absolutely correct that PAfE can end up taking the reputational hit for issues that originate well outside of its control. When something goes wrong in Excel, the add‑in is often the first thing blamed… even when Excel itself has been quietly collecting named ranges like it's a hobby.

While this isn't strictly an IBM‑created problem, it is very much our shared problem, and we agree that ignoring it doesn't help anyone.

Given the feedback in this thread, we are prepared to look into the idea of a startup warning when a workbook is opened. The goal would be to clearly indicate that the workbook may be "dirty," including surfacing the number of named ranges it contains. Triggering this once on open (instead of repeatedly during normal operations) would at least give users a fighting chance to manage the situation proactively , before Excel brings the party to a halt.

In parallel, we'll also explore whether we can contribute to an open‑source, non‑IBM‑supported utility (likely Python‑based) that helps clean up these workbooks.

No promises yet, but the feedback here is well‑reasoned, and hard to ignore. Keep it coming, just maybe don't add any more named ranges while we're talking

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

You're a very convincing group 😊, and you're not wrong.

You're absolutely correct that PAfE can end up taking the reputational hit for issues that originate well outside of its control. When something goes wrong in Excel, the add‑in is often the first thing blamed… even when Excel itself has been quietly collecting named ranges like it's a hobby.

While this isn't strictly an IBM‑created problem, it is very much our shared problem, and we agree that ignoring it doesn't help anyone.

Given the feedback in this thread, we are prepared to look into the idea of a startup warning when a workbook is opened. The goal would be to clearly indicate that the workbook may be "dirty," including surfacing the number of named ranges it contains. Triggering this once on open (instead of repeatedly during normal operations) would at least give users a fighting chance to manage the situation proactively , before Excel brings the party to a halt.

In parallel, we'll also explore whether we can contribute to an open‑source, non‑IBM‑supported utility (likely Python‑based) that helps clean up these workbooks.

No promises yet, but the feedback here is well‑reasoned, and hard to ignore. Keep it coming, just maybe don't add any more named ranges while we're talking

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

You're a very convincing group 😊, and you're not wrong.

You're absolutely correct that PAfE can end up taking the reputational hit for issues that originate well outside of its control. When something goes wrong in Excel, the add‑in is often the first thing blamed… even when Excel itself has been quietly collecting named ranges like it's a hobby.

While this isn't strictly an IBM‑created problem, it is very much our shared problem, and we agree that ignoring it doesn't help anyone.

Given the feedback in this thread, we are prepared to look into the idea of a startup warning when a workbook is opened. The goal would be to clearly indicate that the workbook may be "dirty," including surfacing the number of named ranges it contains. Triggering this once on open (instead of repeatedly during normal operations) would at least give users a fighting chance to manage the situation proactively , before Excel brings the party to a halt.

In parallel, we'll also explore whether we can contribute to an open‑source, non‑IBM‑supported utility (likely Python‑based) that helps clean up these workbooks.

No promises yet, but the feedback here is well‑reasoned, and hard to ignore. Keep it coming, just maybe don't add any more named ranges while we're talking

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hey everyone,

First off, thanks for all your feedback and suggestions, you all have been awesome! Your input really helps us make Planning Analytics for Excel better for everyone.

We understand that 3rd party created named ranges really affect our performance, and we heard your suggestions.

Starting with versions 3.1.8 and 2.2.21, you'll get a heads-up warning if your workbook has more than 1,000 named ranges or more than 1,000 Styles. This version will be released sometime in May 2026. 

What To Do If You See the Warning

- Take a look at your named ranges

- Clean out any you're not using anymore

- See if you can combine some that are similar

- Your workbook will thank you with better performance!

We really appreciate you taking the time to share your experiences and ideas , it makes a real difference!

Xavier

You're a very convincing group 😊, and you're not wrong.

You're absolutely correct that PAfE can end up taking the reputational hit for issues that originate well outside of its control. When something goes wrong in Excel, the add‑in is often the first thing blamed… even when Excel itself has been quietly collecting named ranges like it's a hobby.

While this isn't strictly an IBM‑created problem, it is very much our shared problem, and we agree that ignoring it doesn't help anyone.

Given the feedback in this thread, we are prepared to look into the idea of a startup warning when a workbook is opened. The goal would be to clearly indicate that the workbook may be "dirty," including surfacing the number of named ranges it contains. Triggering this once on open (instead of repeatedly during normal operations) would at least give users a fighting chance to manage the situation proactively , before Excel brings the party to a halt.

In parallel, we'll also explore whether we can contribute to an open‑source, non‑IBM‑supported utility (likely Python‑based) that helps clean up these workbooks.

No promises yet, but the feedback here is well‑reasoned, and hard to ignore. Keep it coming, just maybe don't add any more named ranges while we're talking

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Thanks X - this is great news and will certainly go a long way in alleviating some of the issues faced by customers.

Do you perhaps know if named ranges or styles that are in error e.g. #REF! or linked to unknown/unreachable sources take longer to evaluate/parse than valid ones?

Thinking that may an enhancement to the new feature may be a callout that there are invalid named ranges/styles, and these should be addressed whether or not there is 1 or more than 1000.

Hey everyone,

First off, thanks for all your feedback and suggestions, you all have been awesome! Your input really helps us make Planning Analytics for Excel better for everyone.

We understand that 3rd party created named ranges really affect our performance, and we heard your suggestions.

Starting with versions 3.1.8 and 2.2.21, you'll get a heads-up warning if your workbook has more than 1,000 named ranges or more than 1,000 Styles. This version will be released sometime in May 2026. 

What To Do If You See the Warning

- Take a look at your named ranges

- Clean out any you're not using anymore

- See if you can combine some that are similar

- Your workbook will thank you with better performance!

We really appreciate you taking the time to share your experiences and ideas , it makes a real difference!

Xavier

You're a very convincing group 😊, and you're not wrong.

You're absolutely correct that PAfE can end up taking the reputational hit for issues that originate well outside of its control. When something goes wrong in Excel, the add‑in is often the first thing blamed… even when Excel itself has been quietly collecting named ranges like it's a hobby.

While this isn't strictly an IBM‑created problem, it is very much our shared problem, and we agree that ignoring it doesn't help anyone.

Given the feedback in this thread, we are prepared to look into the idea of a startup warning when a workbook is opened. The goal would be to clearly indicate that the workbook may be "dirty," including surfacing the number of named ranges it contains. Triggering this once on open (instead of repeatedly during normal operations) would at least give users a fighting chance to manage the situation proactively , before Excel brings the party to a halt.

In parallel, we'll also explore whether we can contribute to an open‑source, non‑IBM‑supported utility (likely Python‑based) that helps clean up these workbooks.

No promises yet, but the feedback here is well‑reasoned, and hard to ignore. Keep it coming, just maybe don't add any more named ranges while we're talking

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Thanks X - this is great news and will certainly go a long way in alleviating some of the issues faced by customers.

Do you perhaps know if named ranges or styles that are in error e.g. #REF! or linked to unknown/unreachable sources take longer to evaluate/parse than valid ones?

Thinking that may an enhancement to the new feature may be a callout that there are invalid named ranges/styles, and these should be addressed whether or not there is 1 or more than 1000.

Hey everyone,

First off, thanks for all your feedback and suggestions, you all have been awesome! Your input really helps us make Planning Analytics for Excel better for everyone.

We understand that 3rd party created named ranges really affect our performance, and we heard your suggestions.

Starting with versions 3.1.8 and 2.2.21, you'll get a heads-up warning if your workbook has more than 1,000 named ranges or more than 1,000 Styles. This version will be released sometime in May 2026. 

What To Do If You See the Warning

- Take a look at your named ranges

- Clean out any you're not using anymore

- See if you can combine some that are similar

- Your workbook will thank you with better performance!

We really appreciate you taking the time to share your experiences and ideas , it makes a real difference!

Xavier

You're a very convincing group 😊, and you're not wrong.

You're absolutely correct that PAfE can end up taking the reputational hit for issues that originate well outside of its control. When something goes wrong in Excel, the add‑in is often the first thing blamed… even when Excel itself has been quietly collecting named ranges like it's a hobby.

While this isn't strictly an IBM‑created problem, it is very much our shared problem, and we agree that ignoring it doesn't help anyone.

Given the feedback in this thread, we are prepared to look into the idea of a startup warning when a workbook is opened. The goal would be to clearly indicate that the workbook may be "dirty," including surfacing the number of named ranges it contains. Triggering this once on open (instead of repeatedly during normal operations) would at least give users a fighting chance to manage the situation proactively , before Excel brings the party to a halt.

In parallel, we'll also explore whether we can contribute to an open‑source, non‑IBM‑supported utility (likely Python‑based) that helps clean up these workbooks.

No promises yet, but the feedback here is well‑reasoned, and hard to ignore. Keep it coming, just maybe don't add any more named ranges while we're talking

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hey everyone,

First off, thanks for all your feedback and suggestions, you all have been awesome! Your input really helps us make Planning Analytics for Excel better for everyone.

We understand that 3rd party created named ranges really affect our performance, and we heard your suggestions.

Starting with versions 3.1.8 and 2.2.21, you'll get a heads-up warning if your workbook has more than 1,000 named ranges or more than 1,000 Styles. This version will be released sometime in May 2026. 

What To Do If You See the Warning

- Take a look at your named ranges

- Clean out any you're not using anymore

- See if you can combine some that are similar

- Your workbook will thank you with better performance!

We really appreciate you taking the time to share your experiences and ideas , it makes a real difference!

Xavier

You're a very convincing group 😊, and you're not wrong.

You're absolutely correct that PAfE can end up taking the reputational hit for issues that originate well outside of its control. When something goes wrong in Excel, the add‑in is often the first thing blamed… even when Excel itself has been quietly collecting named ranges like it's a hobby.

While this isn't strictly an IBM‑created problem, it is very much our shared problem, and we agree that ignoring it doesn't help anyone.

Given the feedback in this thread, we are prepared to look into the idea of a startup warning when a workbook is opened. The goal would be to clearly indicate that the workbook may be "dirty," including surfacing the number of named ranges it contains. Triggering this once on open (instead of repeatedly during normal operations) would at least give users a fighting chance to manage the situation proactively , before Excel brings the party to a halt.

In parallel, we'll also explore whether we can contribute to an open‑source, non‑IBM‑supported utility (likely Python‑based) that helps clean up these workbooks.

No promises yet, but the feedback here is well‑reasoned, and hard to ignore. Keep it coming, just maybe don't add any more named ranges while we're talking

Hi Xavier,
Thanks for responding.

tl:dr Would it be possible to have an alert when a book is opened declaring that a book is "dirty"?

I fully understand that the issue of the named ranges is not an issue of IBMs making and the main responsibility of fixing it should rest with the owner of the spreadsheets.
That said
A.  We have never been able to track down root cause of the issue and this has been echoed by many of the other posters on this thread.  Once a customer suffers from this issue, it nearly always comes back, post workbook clean.  Fixing root cause does not seem possible.
B.  PAfE is a cornerstone of the PA Suite, there are almost definitely many people suffering in silence, causing reputational damage.
C.  Just the logistics of trying to resolve the issue in the client rather than in the many, many spreadsheets out there, suggests that the PAfE is the most logical place to resolve the problem.

In short it might not be IBMs responsibility but it is their and our problem.

I understand that PAfE needs to keep track of the named ranges it uses but it does seem to do this "name survey" every time a new cell is selected.  Is the right work being done on the wrong event?

Some thoughts on solutions (easy for me to say!).

1.  An alert that pops up when there are more than 1,000 named ranges (hidden or otherwise) in a workbook, with a link to a webpage explain how to resolve.  The alert could pop-up when the workbook is first opened, rather than on every calculation pass.  This would at least give us an opportunity to actively manage the issue.

2.  Skip over hidden named ranges in when surveying them.

3.  When PAfE creates a named range, set the Comment property to "PAfE".  When testing named ranges only look at named ranges where the Comment = PAfE.

What I suspect is any approach where we test a named range to see if it needs to be looked at, is just as expensive as looking at it in the first place. Once the named range count gets high there is no solution.

=>  An alert on opening that the book is "dirty" would be very helpful.

As outlined in other posts, this behavior is typically caused by VBA code or other add‑ins that do not fully clean up after execution. PAfE relies on named ranges to understand and maintain the structure of reports such as Quick Reports and Universal Reports (static and dynamic). Because of this dependency, removing or avoiding named ranges is not a viable option without impacting core PAfE functionality.

In the cases we've investigated, the underlying issue is the accumulation of a very large number of hidden named ranges. These can interfere both with PAfE's ability to locate the named ranges it needs and with overall Excel performance. This is not something we see across all Planning Analytics users, rather there is a consistent pattern where custom VBA scripts or other add‑ins create short lived named ranges but do not remove them once they are no longer required, allowing them to build up over time.

From our perspective, addressing this by changing PAfE would effectively mean compensating for side effects introduced by external logic, rather than resolving the source of the behavior itself. The more sustainable and reliable approach is to improve script hygiene by explicitly deleting any temporary named ranges at the end of script execution.

We've also observed that some long‑lived Perspectives workbooks have gradually accumulated a large number of named ranges without users being aware of it. Since Perspectives does not rely on named ranges in the same way as PAfE, this often only becomes noticeable when those workbooks are later used with PAfE.

Given the widespread and hidden nature of this problem is it something that IBM would be able to resolve?

It is clear that it is impacting a lot of the user base and we are all finding our own way around the problem, it would be much better if IBM were to change the behaviour of PAfE.

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi all,

Just to confirm we have also seen this problem and also to confirm that VBA is too slow at removing the hidden named ranges.

Hopefully IBM can address this issue.

regards,

Mark

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

I was going to suggest this thread to customers as a useful resource to get ideas on how to deal with this problem until IBM provide some sort of solution but it appears that IBM have now locked down the site to members only, which seems to get away from the spirit of the internet! I am sure the early pioneers of the internet will be spinning in their graves! - apologies if they are still alive :)

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!

Hi Mark,

The connection is resolved.

Non-members should se the content of the threads and posts.

Best regards,

I was going to suggest this thread to customers as a useful resource to get ideas on how to deal with this problem until IBM provide some sort of solution but it appears that IBM have now locked down the site to members only, which seems to get away from the spirit of the internet! I am sure the early pioneers of the internet will be spinning in their graves! - apologies if they are still alive :)

Hi,

We have had an ongoing persistent issue with PAfE, since the first release.

This is the fact that (as I have been told) PAfE tests every named range as you navigate from cell to cell. Why it needs to do this is unknown to me.

Back in Rebecca H's time we were able to get this test removed or at least be less impactful but after a year or so the problem was re-introduced.

Taken in isolation this test shouldn't be too impactful but, across all our customers, around once a month we get a ticket where navigation around a workbook has become painfully slow.   Navigating from one cell to the next has a significant lag. This is always because the workbook contains thousands of (usually) hidden named ranges.

I've just dealt with a case where a customer workbook had 60k hidden named ranges.  None of the customers have ever been able to establish where these names come from.

Whilst taking on board the fact that the workbooks should never have this many hidden named ranges, the fact is that it does occur regularly given a large enough customer base.

Shouldn't PAfE deal with these dirty excel books better?

What is the named range test for, is it really required?  (Some of my reading suggests it might be inherited from the CA client)

Can it be modified to skip over hidden named ranges?

How many users of PAfE across the planet are suffering from this issue without realising it, damaging the reputation of the product?  To me this is the biggest problem, how many people are suffering silence?  If we see it regularly at the InfoCat level this suggests that the problem is widespread.

(Also all the hidden names in the recent example had the text "wrn.allmatrix" in them, if anyone has any idea what might be creating them I would be grateful.  This isn't always the case, in fact I think this is the first time I have seen this specific text in the name.  Web / AI Searching gives a wide variety of conflicting views)

Yours in frustration!