Skip to main content
Solved

After migration the semantic layer can't execute.


rbrandsma
Contributor
Forum|alt.badge.img

Hi!

This week I have been trying to upgrade a client of ours to TX 20.10.66.64 and in this process we have come quite far. We are able to deploy & execute all layers in a project, except for the Semantic layer. 

The error message TX shows us is below:

The account that is mentioned in the parts that I have blurred out is an account that has never existed, nor is mentioned in any connection in the project. 

The databases used in this semantic layer are all on a SQL server that worked correctly before the upgrade of TX. Note: TX was not only upgraded, but also installed on a different application server. 

Created a new endpoint in the existing semantic layer, when trying to deploy and execute this, same error message appeared. 

Deploy steps all succeeded, it fails on the execution step. 

Has someone seen this error message or experienced this before? 

Best answer by rbrandsma

Had a conversation with ​@Thomas Lind about this issue. We were able to resolve this by changing a few settings. 

First in de Usermapping of the service account we added the role membership db_datawriter

 

And in the Endpoint settings we changed the Deployment target & Compatibility level to their default settings. Under Processing we changed the setting to use the Service account. 

 

 

I have now changed the settings of all the semantic endpoints to match these and tested a few by random selection. All are able to deploy and execute. 

Thanks!

View original
Did this topic help you find an answer to your question?

10 replies

Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

rbrandsma
Contributor
Forum|alt.badge.img
  • Author
  • Contributor
  • 13 replies
  • May 28, 2025

Hi ​@Christian Hauggaard

Thanks for your quick response. 

I have followed the article that you linked. Bur unfortunately this did not solve the issue. We even tried to raise the user mapping levels to db_owner instead of db_datareader. 

 


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

@rbrandsma can you please confirm which user is running you SQL Server Analysis Services service? e.g. NT Service\MSSQLServerOLAPService

Please make sure to give this user read access to the MDW

Also can you please send a screenshot of your tabular settings similar to below?

Also can you please confirm if you are using SQL server authentication for your MDW?

 


rory.smith
TimeXtender Xpert
Forum|alt.badge.img+7
  • TimeXtender Xpert
  • 701 replies
  • May 30, 2025

Hi,

Assuming you are trying to leverage the built-in service account for SSAS: NT Service\MSSQLServerOLAPService (or slightly different naming if you are running a named instance)

 

if TimeXtender is not running on the same machine as your SQL Server / SSAS instance and both VMs are Windows AD domain-joined or not joined to a domain at all then you need to use SQL Server Authentication or a service account to solve this.

The NT Service \**** accounts are local accounts that cannot be interacted with from outside the VM (mostly). If your VMs are domain-joined you can use a “traditional” service account to have SSAS authenticate to SSAS. If your setup uses local accounts only, you will need to use SQL Server authentication (and should really consider using Windows AD / Entra ID / another identity provider).


rbrandsma
Contributor
Forum|alt.badge.img
  • Author
  • Contributor
  • 13 replies
  • June 2, 2025

Hi ​@Christian Hauggaard,

As requested the screenshots 

SQL Server Analysis Services Service & User:

 This user has access to the MDW database mentioned in the error message:

Tabular endpoint settings:

 

They are not using SQL Server authentication (see screenshot below). As mentioned this was an upgrade to a new version of TX and these are the settings taken over from the “older” version of TX. 

 

 

TX is installed on an application server and connects to a database server. 


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

@rbrandsma can you please try using SQL server authentication instead?


rbrandsma
Contributor
Forum|alt.badge.img
  • Author
  • Contributor
  • 13 replies
  • June 2, 2025

@Christian Hauggaard 

We can certainly try!

One question though….In your screenshot you are using the built in SA account. I reckon we should not be using that. 

But what account should we use? The Service account from the application server that is used to start the TimeXtender Services? Or does this not matter?

I disabled the global database option of the MDW datawarehouse and changed the authentication to SQL Server Authentication. Then the admin I'm working with filled in his credentials. Saved the changes and tried to execute the semantic layer again. There was no change in the results. Same error message appeared on executing the semantic layer. 


Thomas Lind
Community Manager
Forum|alt.badge.img+5
  • Community Manager
  • 1094 replies
  • June 2, 2025

Hi ​@rbrandsma 

Can you try to change the two settings Deployment Target and Compability Level so they are their default values.

Like this.

 


rbrandsma
Contributor
Forum|alt.badge.img
  • Author
  • Contributor
  • 13 replies
  • June 3, 2025

Hi ​@Thomas Lind 

Tried changing the settings you advised, but still the same error message appears. Also tried reinstalling the Analysis Services client libraries, all without any result. 

Would there be any chance to have some one assist with this in a different capacity?


rbrandsma
Contributor
Forum|alt.badge.img
  • Author
  • Contributor
  • 13 replies
  • Answer
  • June 3, 2025

Had a conversation with ​@Thomas Lind about this issue. We were able to resolve this by changing a few settings. 

First in de Usermapping of the service account we added the role membership db_datawriter

 

And in the Endpoint settings we changed the Deployment target & Compatibility level to their default settings. Under Processing we changed the setting to use the Service account. 

 

 

I have now changed the settings of all the semantic endpoints to match these and tested a few by random selection. All are able to deploy and execute. 

Thanks!


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings