Temp View difference to Perm Views
- paulsimon
- MVP
- Posts: 808
- Joined: Sat Sep 03, 2011 11:10 pm
- OLAP Product: TM1
- Version: PA 2.0.5
- Excel Version: 2016
- Contact:
Temp View difference to Perm Views
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
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
-
- Posts: 9
- Joined: Mon Oct 26, 2009 3:42 pm
- OLAP Product: TM1
- Version: 9.1 SP4 HF2 x64
- Excel Version: 2003
Re: Temp View difference to Perm Views
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
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
-
- MVP
- Posts: 2831
- Joined: Tue Feb 16, 2010 2:39 pm
- OLAP Product: TM1, Palo
- Version: Beginning of time thru 10.2
- Excel Version: 2003-2007-2010-2013
- Location: Atlanta, GA
- Contact:
Re: Temp View difference to Perm Views
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).
- paulsimon
- MVP
- Posts: 808
- Joined: Sat Sep 03, 2011 11:10 pm
- OLAP Product: TM1
- Version: PA 2.0.5
- Excel Version: 2016
- Contact:
Re: Temp View difference to Perm Views
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
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
-
- MVP
- Posts: 3113
- Joined: Mon Dec 29, 2008 6:26 pm
- OLAP Product: TM1, Jedox
- Version: PAL 2.0.9.18
- Excel Version: Microsoft 365
- Location: Brussels, Belgium
- Contact:
Re: Temp View difference to Perm 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.
Best regards,
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
-
- Posts: 78
- Joined: Wed Jul 31, 2013 4:32 am
- OLAP Product: Cognos TM1, EP, Analyst
- Version: 10.2.2
- Excel Version: 2013
- Location: Sydney AU
Re: Temp View difference to Perm Views
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).
MK
-
- MVP
- Posts: 3652
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: Temp View difference to Perm Views
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.
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.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
- Steve Rowe
- Site Admin
- Posts: 2415
- Joined: Wed May 14, 2008 4:25 pm
- OLAP Product: TM1
- Version: TM1 v6,v7,v8,v9,v10,v11+PAW
- Excel Version: Nearly all of them
Re: Temp View difference to Perm Views
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
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
Technical Director
www.infocat.co.uk
www.infocat.co.uk
- paulsimon
- MVP
- Posts: 808
- Joined: Sat Sep 03, 2011 11:10 pm
- OLAP Product: TM1
- Version: PA 2.0.5
- Excel Version: 2016
- Contact:
Re: Temp View difference to Perm Views
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
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
- PavoGa
- MVP
- Posts: 617
- Joined: Thu Apr 18, 2013 6:59 pm
- OLAP Product: TM1
- Version: 10.2.2 FP7, PA2.0.9.1
- Excel Version: 2013 PAW
- Location: Charleston, Tennessee
Re: Temp View difference to Perm Views
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.
Ty
Cleveland, TN
Cleveland, TN
-
- MVP
- Posts: 3652
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: Temp View difference to Perm Views
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.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
-
- MVP
- Posts: 3652
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: Temp View difference to Perm Views
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.)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.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
- paulsimon
- MVP
- Posts: 808
- Joined: Sat Sep 03, 2011 11:10 pm
- OLAP Product: TM1
- Version: PA 2.0.5
- Excel Version: 2016
- Contact:
Re: Temp View difference to Perm Views
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
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
- PavoGa
- MVP
- Posts: 617
- Joined: Thu Apr 18, 2013 6:59 pm
- OLAP Product: TM1
- Version: 10.2.2 FP7, PA2.0.9.1
- Excel Version: 2013 PAW
- Location: Charleston, Tennessee
Re: Temp View difference to Perm Views
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.lotsaram wrote: ↑Mon Feb 25, 2019 1:12 pmYou 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.
Ty
Cleveland, TN
Cleveland, TN
-
- MVP
- Posts: 3652
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: Temp View difference to Perm Views
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.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
-
- Posts: 72
- Joined: Wed Aug 15, 2018 3:18 pm
- OLAP Product: TM1
- Version: 10.3
- Excel Version: 2016
Re: Temp View difference to Perm Views
Hi, SteveSteve 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.
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
-
- MVP
- Posts: 3652
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: Temp View difference to Perm Views
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.
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.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.