TM1 Forum

Hi

We previously used code like this

IF( ViewExists( vCube , vView ) = 0 ) ;
ViewCreate( vCube , vView ) ;
ENDIF ;

ViewSubsetAssign( vCube , vView , vMeasDim, vMeasSub ) ;
etc

This worked fine with permanent views, since if the view already existed the ViewSubsetAssign modified it as required.

However, this technique does not work reliably with Temp Views. It was a while before we spotted this as our Temp View names include a time stamp that goes down to seconds, so in most cases the view did not already exist. It was only when a series of calls were being made in a tight loop that we noticed a problem.

If using Temp Views you need to use something along the following lines

IF( ViewExists( vCube , vView ) = 1 ) ;
ViewDestroy( vCube , vView ) ;
ENDIF ;
ViewCreate( vCube , vView , 1 ) ;

ViewSubsetAssign( vCube , vView , vMeasDim, vMeasSub ) ;

Regards

Paul Simon

Hi Paul,

I thought temp views and subsets only existed whilst the TI was running and there was no need to destroy them. I guess if you have a "permanent" view with the same name then maybe you do?

Cheers

Mike

paulsimon wrote: ↑Wed Feb 20, 2019 10:45 am If using Temp Views you need to use something along the following lines

IF( ViewExists( vCube , vView ) = 1 ) ;
ViewDestroy( vCube , vView ) ;
ENDIF ;
ViewCreate( vCube , vView , 1 ) ;

ViewSubsetAssign( vCube , vView , vMeasDim, vMeasSub ) ;

FWIW, this is exactly what I've been doing in all my TI's for a long time (except I just started using the "1" parameter in view and subset creates a couple of years ago).

Hi Mike

In this scenario we had a process that takes a parameter of an Entity and it is normally run directly from a web sheet. However, we sometimes need to do a bulk run for all Entities. To do that we have a master process that loops through a subset of Entities and calls the individual Entity process, passing in each Entity from the subset. Now, because the temp views are all being created within the scope of the same master process they seem to persist from one call to the next. That is why you need to destroy the temp view because there is a risk of clash even if the temp view has a name with a timestamp down to seconds since in some cases the process may take less than a second to run. This clash did not used to be a problem with permanent views, since the ViewSubsetAssign seems to modify the view correctly. However, it is a problem with Temp Views.

Regards

Paul Simon

paulsimon wrote: ↑Wed Feb 20, 2019 11:02 pm However, it is a problem with Temp Views.

Indeed. IBM should look into that because to me the temporary objects relate to the called process. Even if I call it 1,000 times, I don’t need/want to explicitly delete views and subsets - they’re temporary for a reason.

What I would do is, attached a random number (10 digits) to the view/subset name every time a temporary object is used. And I've removed the check and remove existing view/subsets (the chance of the same object name is used in the same process chain is pretty low). Since they are temporary objects, I don't have to worry about deleting them (even process fails).

In my opinion the original implementation of temporary objects being only available to the immediate process which created them is seriously flawed and constitutes a product defect.

Temporary subsets & views being only available to the TI creating them excludes the possibility of a functional library being able to utilize temporary objects. So currently if you want to leverage temp objects all code to create and manage the subsets and views needs to be replicated in each and every process. This goes against every best practice principle for developing applications you can think of. Code is distributed not centralized, unnecessarily duplicated, more effort to maintain, multiple not single point unit tests. Suffice to say gets my goat.

A proper and correct implementation of temporary objects would have them available within the same TI "transaction" that is If one process calls a library function via ExecuteProcess which creates a temporary view, then the calling process should be able to use the view.

I remain very hopeful that this evidence of temp objects persisting beyond the creating process is actually evidence not of a bug but if IBM seeking to address the initial flawed implementation and do it properly.

As ever the most right thing is to give the developer the tools to make the choice themselves of the scope of the object.
Flag values of
0 - Permanent object
1 - Temp and local to the creating TI only.
2 - Temp and global to the entire TI chain.

Note this is a suggestion, flag 2 does not exist

Hi lotsaram

We are using PA 2.0.5. My understanding is that a temp view created in a master process is available to any process called by that process.

We have a case here where we use a generic process to transfer data from one cube to another.

The calling process first uses a temp view to clear existing data from the relevant area of the cube, it then creates another temp view to act as the source view and it passes the name of that temp view into the generic process as a parameter.

The generic process reads from the temp view passed in as a parameter to transfer data from the source cube to the destination cube. The main purpose of the generic process is to do some attribute lookups on the data as it passes through, because the target cube has more dimensions than the source cube.

Anyway this appears to work. We run daily checks to ensure that the two cubes are in step.

Regards

Paul Simon

I have found that a temporary subset is not available to a subsequent MDX query within the same TI. In that case, the first query has be a permanent subset and is removed in the Epilog.

PavoGa wrote: ↑Mon Feb 25, 2019 12:39 pm I have found that a temporary subset is not available to a subsequent MDX query within the same TI. In that case, the first query has be a permanent subset and is removed in the Epilog.

You mean using one subset as the base set for another? As in either ...
{FILTER( [Dimension].[Temp Subset], filter condition )}
or
{FILTER( {TM1SubsetToSet( [Dimension], "Temp Subset" )}, filter condition )}

If yes we have noticed that too but I put it down to "expected behavior". Easy enough to work around by reusing the whole MDX of the first subset and embedding it in the 2nd as opposed to trying to use the subset.

If that's not what you mean then probably others don't know either not just me.

paulsimon wrote: ↑Mon Feb 25, 2019 11:02 am We are using PA 2.0.5. My understanding is that a temp view created in a master process is available to any process called by that process.

We have a case here where we use a generic process to transfer data from one cube to another.

The calling process first uses a temp view to clear existing data from the relevant area of the cube, it then creates another temp view to act as the source view and it passes the name of that temp view into the generic process as a parameter.

That would be massive news. If it's true, quite nice of IBM to do it and not actually communicate the change! (Especially as there was an RFE for this which was denied.)

Hi Lotsaram

I am probably too stupid to realise that it couldn't be done and just went ahead and did it since it seemed like a logical thing to be able to do.

Anyway, I suggest you try an experiment yourself to confirm it.

Regards

Paul

lotsaram wrote: ↑Mon Feb 25, 2019 1:12 pm

PavoGa wrote: ↑Mon Feb 25, 2019 12:39 pm I have found that a temporary subset is not available to a subsequent MDX query within the same TI. In that case, the first query has be a permanent subset and is removed in the Epilog.

You mean using one subset as the base set for another? As in either ...
{FILTER( [Dimension].[Temp Subset], filter condition )}
or
{FILTER( {TM1SubsetToSet( [Dimension], "Temp Subset" )}, filter condition )}

If yes we have noticed that too but I put it down to "expected behavior". Easy enough to work around by reusing the whole MDX of the first subset and embedding it in the 2nd as opposed to trying to use the subset.

If that's not what you mean then probably others don't know either not just me.

That was exactly what I meant, but I was a little surprised it did not work. I go ahead and add the first one as a regular subset and to shorten the code of the second subset and remove it in the Epilog.

paulsimon wrote: ↑Mon Feb 25, 2019 2:34 pm Hi Lotsaram

I am probably too stupid to realise that it couldn't be done and just went ahead and did it since it seemed like a logical thing to be able to do.

Anyway, I suggest you try an experiment yourself to confirm it.

Regards

Paul

Buried away (not in the release notes, mind you but buried in the reference material) the actually is a statement that the scope of temp objects changed as of v 11.3.0 from the immediate process to include sibling and ancestor processes that are part of the same ExecuteProcess chain.
However from some defects which I have raised I know that temp subsets don't work correctly on alternate hierarchies until 11.4. Therefore I would recommend 11.4 as the minimum version for PA for anyone moving from 10.2.2 to v11.

Steve Rowe wrote: ↑Thu Feb 21, 2019 8:18 am As every the most right thing is to give the developer the tools to make the choice themselves of the scope of the object.
Flag values of
0 - Permanent object
1 - Temp and local to the creating TI only.
2 - Temp and global to the entire TI chain.

Hi, Steve

I just want to confirm for my understanding - If we want to assign the same view across all ExecuteProcess() resides in current TI, then we should put Flag 2 instead of 1?


https://www.ibm.com/support/pages/tm1-1 ... ry-objects

Thank You for sharing - I did not know about Flag 2. IBM tech note also did not include.

Dharav

There is no flag 2!
This was Steve’s suggestion at the time that temp objects existed only for the immediate process.
Temp objects are now available throughout the whole ExecuteProcess chain.