Hi All, 

We've got pre-defined views that were set up in the Remote Desktop via Perspectives, and therefore they were .vue file type. 

Over the month end some of our less experienced administrators changed the view through PAW to include new elements and then saved it to the server. This changed the file type to .xbf. 

However, now when we try to run the processes they fail where ever there is a Viewsubsetassign or viewexists statement, with the error saying it cannot find the view even though it is stated in the Data Source, and the preview returns. I've run the same processes on other .Vue views and it works just fine. 

I'm wondering if anyone has experienced this or can tell me why it is happening (or supply a fix ? ) as with the Remote Desktop now deprecated. We have no way to run these critical processes. 

Hi Phillip,

Yes, the TM1 native views had been saved as the MDX views, the warning that the views will be replaced were given upon saving.

The isssues with the process data sources would be expected as the MDX view would impose a different order and not match the process data source ste up. 

If you have the TI processes to recreate those views, then you should be able to continue to use them as a datasource.

The option to save the view as the native view or MDX view is going to be available on the next PAW release in October 2024.

Best regards,

Hi All, 

We've got pre-defined views that were set up in the Remote Desktop via Perspectives, and therefore they were .vue file type. 

Over the month end some of our less experienced administrators changed the view through PAW to include new elements and then saved it to the server. This changed the file type to .xbf. 

However, now when we try to run the processes they fail where ever there is a Viewsubsetassign or viewexists statement, with the error saying it cannot find the view even though it is stated in the Data Source, and the preview returns. I've run the same processes on other .Vue views and it works just fine. 

I'm wondering if anyone has experienced this or can tell me why it is happening (or supply a fix ? ) as with the Remote Desktop now deprecated. We have no way to run these critical processes. 

Svetlana, the issue I have is that the TI process doesn't even recognise that the view exists. Even when I run Bedrock the ViewExists statements fail. 

I can delete the view and use Bedrock to set them up again each time, but to make small adjustments each time this is very long winded. 

------------------------------
Phillip Lidstone

Original Message:
Sent: Wed October 16, 2024 01:01 PM
From: Svetlana Pestsova
Subject: xbf views and TurboIntegrator Issues

Hi Phillip,

Yes, the TM1 native views had been saved as the MDX views, the warning that the views will be replaced were given upon saving.

The isssues with the process data sources would be expected as the MDX view would impose a different order and not match the process data source ste up. 

If you have the TI processes to recreate those views, then you should be able to continue to use them as a datasource.

The option to save the view as the native view or MDX view is going to be available on the next PAW release in October 2024.

Best regards,

------------------------------
Svetlana Pestsova
IBM Planning Analytics Product Manager

Original Message:
Sent: Wed October 16, 2024 10:26 AM
From: Phillip Lidstone
Subject: xbf views and TurboIntegrator Issues

Hi All, 

We've got pre-defined views that were set up in the Remote Desktop via Perspectives, and therefore they were .vue file type. 

Over the month end some of our less experienced administrators changed the view through PAW to include new elements and then saved it to the server. This changed the file type to .xbf. 

However, now when we try to run the processes they fail where ever there is a Viewsubsetassign or viewexists statement, with the error saying it cannot find the view even though it is stated in the Data Source, and the preview returns. I've run the same processes on other .Vue views and it works just fine. 

I'm wondering if anyone has experienced this or can tell me why it is happening (or supply a fix ? ) as with the Remote Desktop now deprecated. We have no way to run these critical processes. 

------------------------------
Phillip Lidstone
------------------------------

Phillip,

I do wonder why you would need those views in the first place in your database, with a name that users can attribute meaning to ? Even more, can your users save/overwrite the views ? I see that you write about inexperienced administrator users. Then I can understand overwriting but there's definitely a need for training then.

What I do is have 1 ZZZ_Tmp public view on each data cube. It can be easily created with a TI process.

The view is not huge, rather, it's the most tiny view you can imagine: 1 cell. Meaning, 1 element per dimension, all dimensions stored in the Context area,

and the order follows the order of the cube dimensions.

Yes, technically, users can still open and overwrite, but chances are rather small.

Each dimension (that appears in any of these cubes) will have a ZZZ_Tmp public subset too, containing 1 element. The first element in the dimension.

The Prolog tab then creates and assigns a new (temporary) view to the process and the rest is as expected.

------------------------------
Wim Gielis

Original Message:
Sent: Thu October 17, 2024 10:08 AM
From: Phillip Lidstone
Subject: xbf views and TurboIntegrator Issues

Svetlana, the issue I have is that the TI process doesn't even recognise that the view exists. Even when I run Bedrock the ViewExists statements fail. 

I can delete the view and use Bedrock to set them up again each time, but to make small adjustments each time this is very long winded. 

------------------------------
Phillip Lidstone

Original Message:
Sent: Wed October 16, 2024 01:01 PM
From: Svetlana Pestsova
Subject: xbf views and TurboIntegrator Issues

Hi Phillip,

Yes, the TM1 native views had been saved as the MDX views, the warning that the views will be replaced were given upon saving.

The isssues with the process data sources would be expected as the MDX view would impose a different order and not match the process data source ste up. 

If you have the TI processes to recreate those views, then you should be able to continue to use them as a datasource.

The option to save the view as the native view or MDX view is going to be available on the next PAW release in October 2024.

Best regards,

------------------------------
Svetlana Pestsova
IBM Planning Analytics Product Manager

Original Message:
Sent: Wed October 16, 2024 10:26 AM
From: Phillip Lidstone
Subject: xbf views and TurboIntegrator Issues

Hi All, 

We've got pre-defined views that were set up in the Remote Desktop via Perspectives, and therefore they were .vue file type. 

Over the month end some of our less experienced administrators changed the view through PAW to include new elements and then saved it to the server. This changed the file type to .xbf. 

However, now when we try to run the processes they fail where ever there is a Viewsubsetassign or viewexists statement, with the error saying it cannot find the view even though it is stated in the Data Source, and the preview returns. I've run the same processes on other .Vue views and it works just fine. 

I'm wondering if anyone has experienced this or can tell me why it is happening (or supply a fix ? ) as with the Remote Desktop now deprecated. We have no way to run these critical processes. 

------------------------------
Phillip Lidstone
------------------------------

Hi Wim. The issue relates to the fact our company is now in a position that we only have one developer, and one SME. 

Therefore we rely on users to define their views and our admins build them in PAW. 

We historically have the just written general TI to export those views or picked up those views for other purposes. 

Ideally we would do what you say but that would require far more dedicated resources. 

Phillip,

I do wonder why you would need those views in the first place in your database, with a name that users can attribute meaning to ? Even more, can your users save/overwrite the views ? I see that you write about inexperienced administrator users. Then I can understand overwriting but there's definitely a need for training then.

What I do is have 1 ZZZ_Tmp public view on each data cube. It can be easily created with a TI process.

The view is not huge, rather, it's the most tiny view you can imagine: 1 cell. Meaning, 1 element per dimension, all dimensions stored in the Context area,

and the order follows the order of the cube dimensions.

Yes, technically, users can still open and overwrite, but chances are rather small.

Each dimension (that appears in any of these cubes) will have a ZZZ_Tmp public subset too, containing 1 element. The first element in the dimension.

The Prolog tab then creates and assigns a new (temporary) view to the process and the rest is as expected.

------------------------------
Wim Gielis

Original Message:
Sent: Thu October 17, 2024 10:08 AM
From: Phillip Lidstone
Subject: xbf views and TurboIntegrator Issues

Svetlana, the issue I have is that the TI process doesn't even recognise that the view exists. Even when I run Bedrock the ViewExists statements fail. 

I can delete the view and use Bedrock to set them up again each time, but to make small adjustments each time this is very long winded. 

------------------------------
Phillip Lidstone

Original Message:
Sent: Wed October 16, 2024 01:01 PM
From: Svetlana Pestsova
Subject: xbf views and TurboIntegrator Issues

Hi Phillip,

Yes, the TM1 native views had been saved as the MDX views, the warning that the views will be replaced were given upon saving.

The isssues with the process data sources would be expected as the MDX view would impose a different order and not match the process data source ste up. 

If you have the TI processes to recreate those views, then you should be able to continue to use them as a datasource.

The option to save the view as the native view or MDX view is going to be available on the next PAW release in October 2024.

Best regards,

------------------------------
Svetlana Pestsova
IBM Planning Analytics Product Manager

Original Message:
Sent: Wed October 16, 2024 10:26 AM
From: Phillip Lidstone
Subject: xbf views and TurboIntegrator Issues

Hi All, 

We've got pre-defined views that were set up in the Remote Desktop via Perspectives, and therefore they were .vue file type. 

Over the month end some of our less experienced administrators changed the view through PAW to include new elements and then saved it to the server. This changed the file type to .xbf. 

However, now when we try to run the processes they fail where ever there is a Viewsubsetassign or viewexists statement, with the error saying it cannot find the view even though it is stated in the Data Source, and the preview returns. I've run the same processes on other .Vue views and it works just fine. 

I'm wondering if anyone has experienced this or can tell me why it is happening (or supply a fix ? ) as with the Remote Desktop now deprecated. We have no way to run these critical processes. 

------------------------------
Phillip Lidstone
------------------------------

Hi All, 

We've got pre-defined views that were set up in the Remote Desktop via Perspectives, and therefore they were .vue file type. 

Over the month end some of our less experienced administrators changed the view through PAW to include new elements and then saved it to the server. This changed the file type to .xbf. 

However, now when we try to run the processes they fail where ever there is a Viewsubsetassign or viewexists statement, with the error saying it cannot find the view even though it is stated in the Data Source, and the preview returns. I've run the same processes on other .Vue views and it works just fine. 

I'm wondering if anyone has experienced this or can tell me why it is happening (or supply a fix ? ) as with the Remote Desktop now deprecated. We have no way to run these critical processes.