Support named ranges to avoid issue KB01369

"Editing... directly... replacing cell references with named ranges works already" - but as soon as you recalculate/resize, all the named ranges in the formula are replaced by cell references again.

In response to Jeremy Tinkler, ""Editing... directly... replacing cell r..." older versions didn't do this, some where around 2017 they decided to "reinterpret" your cell references and overwrite your formula where older datalinks did not. For instance, I am dealing with this nasty "Microsoft is Waiting on OLE issue" using Calculated Data to find a Maximum. However, if i delete the absolute reference in the formula bar and CTL-SHIFT-ENTER to maintain the array I can query all the data I want without getting the error. If I click the range of data in the Calculated Data Tab, EVERY SINGLE ENTRY makes me click ok, and thats a pain on 47 tags. Not going to deal with that for 1000 metering tags which is why I find more and more reasons to use C# and AF SDK so I never have to use datalink for anything.   Long story short, the Cell references in the formula bar are over written by the calculated data module with the cellular range, but for some reason it seems to magically work again without throwing the OLE issue. I wish the module would not over write our manually created formula like the old days. I can't see why it is a "feature" to overwrite the user hard coded excel arrays.

In response to Jeremy Tinkler, ""Editing... directly... replacing cell r..." older versions didn't do this, some where around 2017 they decided to "reinterpret" your cell references and overwrite your formula where older datalinks did not. For instance, I am dealing with this nasty "Microsoft is Waiting on OLE issue" using Calculated Data to find a Maximum. However, if i delete the absolute reference in the formula bar and CTL-SHIFT-ENTER to maintain the array I can query all the data I want without getting the error. If I click the range of data in the Calculated Data Tab, EVERY SINGLE ENTRY makes me click ok, and thats a pain on 47 tags. Not going to deal with that for 1000 metering tags which is why I find more and more reasons to use C# and AF SDK so I never have to use datalink for anything.   Long story short, the Cell references in the formula bar are over written by the calculated data module with the cellular range, but for some reason it seems to magically work again without throwing the OLE issue. I wish the module would not over write our manually created formula like the old days. I can't see why it is a "feature" to overwrite the user hard coded excel arrays.

In response to Jeremy Tinkler, ""Editing... directly... replacing cell r..." older versions didn't do this, some where around 2017 they decided to "reinterpret" your cell references and overwrite your formula where older datalinks did not. For instance, I am dealing with this nasty "Microsoft is Waiting on OLE issue" using Calculated Data to find a Maximum. However, if i delete the absolute reference in the formula bar and CTL-SHIFT-ENTER to maintain the array I can query all the data I want without getting the error. If I click the range of data in the Calculated Data Tab, EVERY SINGLE ENTRY makes me click ok, and thats a pain on 47 tags. Not going to deal with that for 1000 metering tags which is why I find more and more reasons to use C# and AF SDK so I never have to use datalink for anything.   Long story short, the Cell references in the formula bar are over written by the calculated data module with the cellular range, but for some reason it seems to magically work again without throwing the OLE issue. I wish the module would not over write our manually created formula like the old days. I can't see why it is a "feature" to overwrite the user hard coded excel arrays.

In response to Jeremy Tinkler, ""Editing... directly... replacing cell r..." older versions didn't do this, some where around 2017 they decided to "reinterpret" your cell references and overwrite your formula where older datalinks did not. For instance, I am dealing with this nasty "Microsoft is Waiting on OLE issue" using Calculated Data to find a Maximum. However, if i delete the absolute reference in the formula bar and CTL-SHIFT-ENTER to maintain the array I can query all the data I want without getting the error. If I click the range of data in the Calculated Data Tab, EVERY SINGLE ENTRY makes me click ok, and thats a pain on 47 tags. Not going to deal with that for 1000 metering tags which is why I find more and more reasons to use C# and AF SDK so I never have to use datalink for anything.   Long story short, the Cell references in the formula bar are over written by the calculated data module with the cellular range, but for some reason it seems to magically work again without throwing the OLE issue. I wish the module would not over write our manually created formula like the old days. I can't see why it is a "feature" to overwrite the user hard coded excel arrays.

In response to Jeremy Tinkler, ""Editing... directly... replacing cell r..." older versions didn't do this, some where around 2017 they decided to "reinterpret" your cell references and overwrite your formula where older datalinks did not. For instance, I am dealing with this nasty "Microsoft is Waiting on OLE issue" using Calculated Data to find a Maximum. However, if i delete the absolute reference in the formula bar and CTL-SHIFT-ENTER to maintain the array I can query all the data I want without getting the error. If I click the range of data in the Calculated Data Tab, EVERY SINGLE ENTRY makes me click ok, and thats a pain on 47 tags. Not going to deal with that for 1000 metering tags which is why I find more and more reasons to use C# and AF SDK so I never have to use datalink for anything.   Long story short, the Cell references in the formula bar are over written by the calculated data module with the cellular range, but for some reason it seems to magically work again without throwing the OLE issue. I wish the module would not over write our manually created formula like the old days. I can't see why it is a "feature" to overwrite the user hard coded excel arrays.

In response to Jeremy Tinkler, ""Editing... directly... replacing cell r..." older versions didn't do this, some where around 2017 they decided to "reinterpret" your cell references and overwrite your formula where older datalinks did not. For instance, I am dealing with this nasty "Microsoft is Waiting on OLE issue" using Calculated Data to find a Maximum. However, if i delete the absolute reference in the formula bar and CTL-SHIFT-ENTER to maintain the array I can query all the data I want without getting the error. If I click the range of data in the Calculated Data Tab, EVERY SINGLE ENTRY makes me click ok, and thats a pain on 47 tags. Not going to deal with that for 1000 metering tags which is why I find more and more reasons to use C# and AF SDK so I never have to use datalink for anything.   Long story short, the Cell references in the formula bar are over written by the calculated data module with the cellular range, but for some reason it seems to magically work again without throwing the OLE issue. I wish the module would not over write our manually created formula like the old days. I can't see why it is a "feature" to overwrite the user hard coded excel arrays.

In response to Jeremy Tinkler, ""Editing... directly... replacing cell r..." older versions didn't do this, some where around 2017 they decided to "reinterpret" your cell references and overwrite your formula where older datalinks did not. For instance, I am dealing with this nasty "Microsoft is Waiting on OLE issue" using Calculated Data to find a Maximum. However, if i delete the absolute reference in the formula bar and CTL-SHIFT-ENTER to maintain the array I can query all the data I want without getting the error. If I click the range of data in the Calculated Data Tab, EVERY SINGLE ENTRY makes me click ok, and thats a pain on 47 tags. Not going to deal with that for 1000 metering tags which is why I find more and more reasons to use C# and AF SDK so I never have to use datalink for anything.   Long story short, the Cell references in the formula bar are over written by the calculated data module with the cellular range, but for some reason it seems to magically work again without throwing the OLE issue. I wish the module would not over write our manually created formula like the old days. I can't see why it is a "feature" to overwrite the user hard coded excel arrays.

In response to Jeremy Tinkler, ""Editing... directly... replacing cell r..." older versions didn't do this, some where around 2017 they decided to "reinterpret" your cell references and overwrite your formula where older datalinks did not. For instance, I am dealing with this nasty "Microsoft is Waiting on OLE issue" using Calculated Data to find a Maximum. However, if i delete the absolute reference in the formula bar and CTL-SHIFT-ENTER to maintain the array I can query all the data I want without getting the error. If I click the range of data in the Calculated Data Tab, EVERY SINGLE ENTRY makes me click ok, and thats a pain on 47 tags. Not going to deal with that for 1000 metering tags which is why I find more and more reasons to use C# and AF SDK so I never have to use datalink for anything.   Long story short, the Cell references in the formula bar are over written by the calculated data module with the cellular range, but for some reason it seems to magically work again without throwing the OLE issue. I wish the module would not over write our manually created formula like the old days. I can't see why it is a "feature" to overwrite the user hard coded excel arrays.

Customer would like to enter a dynamic range of tag names in the Data Item field for a Sampled Data function in DataLink. Currently, the Data Item field only takes a single tag or a specified Excel range of cells. Customer would like to add and remove tag names and use a dynamic range of tag names in the Data Item field.

As tinklerj mentions, it is possible enter a named range in the cell directly, but since Datalink replaces it immediately, it defeats the purpose of a named range. The usefulness of named ranges is that they can be made to be dynamic to change size depending on how many points there are etc.