Skip to main content
Solved

Partition Schemas

  • February 8, 2023
  • 8 replies
  • 111 views

rvgfox
Problem Solver
Forum|alt.badge.img+4
  • Problem Solver
  • 227 replies

I’ve detected that if you have the same table in DSA and MDW. let say DSA.Invoices and MDW.Invoices for example, and you define partition for that, both tables share the same partition schemas and partition functions in the SQL Server database.

It’s a problem when you try to add or remove field from whatever table.

Best answer by Christian Hauggaard

Hi @rvgfox 

I was able to reproduce the issue.

The currency tables above have the same template and partition settings, and both deployed and executed successfully. However, once I deleted the “currencytype” field in the Sales data area (i.e. a field from the source table), I received the following error upon deployment of the Sales data area.

In order to resolve the error, I went back into table settings and set the table partition template to “None” on both tables. Then I was able to deploy successfully again.

I then changed the table partitioning back to the previous settings and it worked again. So as a workaround, can you please try setting the template to “None” on both tables, and deploy, before enabling the table partition template again?

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

8 replies

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

Hi @rvgfox can you please add a few screenshots of your setup and the steps taken to reproduce the error? Thanks!


rvgfox
Problem Solver
Forum|alt.badge.img+4
  • Author
  • Problem Solver
  • 227 replies
  • February 8, 2023

I’ve two tables with the same name in diferent schemas:

The partition configuration it’s the same in both tables:

Now, I’m not be able to reproduce the error, but in the SQL Server both tables share the same partition schemas and partition functions and if one deploy & execute proccess try to drop and recreate one of the tables it gets an error.

 


rory.smith
TimeXtender Xpert
Forum|alt.badge.img+7
  • TimeXtender Xpert
  • 664 replies
  • February 9, 2023

Are your databases for DSA and MDW separate or the same one? If the latter, do you have a default schema behaviour for all items in DSA and MDW? If not, I guess it may be that TX overwrites the DSA objects with MDW ones if you deploy the latter.


rvgfox
Problem Solver
Forum|alt.badge.img+4
  • Author
  • Problem Solver
  • 227 replies
  • February 9, 2023

The database it’s the same, but they have diferent schemas:

 

 


rory.smith
TimeXtender Xpert
Forum|alt.badge.img+7
  • TimeXtender Xpert
  • 664 replies
  • February 9, 2023

Hi,

 

OK - could it be that some central objects for partitioning end up in the aux schema and then have the same name? I usually put the layer name in all schemas, especially when I am sharing a database. So dsa_etl, dsa, mdw_etl, mdw, etc.


rvgfox
Problem Solver
Forum|alt.badge.img+4
  • Author
  • Problem Solver
  • 227 replies
  • February 14, 2023

Hi @rory.smith the problem isn’t in the schema name, it’s in the object name, it cannot be the same because in SQL server the partition schema and the function are created using the object name, without the schema.


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

Hi @rvgfox 

I was able to reproduce the issue.

The currency tables above have the same template and partition settings, and both deployed and executed successfully. However, once I deleted the “currencytype” field in the Sales data area (i.e. a field from the source table), I received the following error upon deployment of the Sales data area.

In order to resolve the error, I went back into table settings and set the table partition template to “None” on both tables. Then I was able to deploy successfully again.

I then changed the table partitioning back to the previous settings and it worked again. So as a workaround, can you please try setting the template to “None” on both tables, and deploy, before enabling the table partition template again?


rvgfox
Problem Solver
Forum|alt.badge.img+4
  • Author
  • Problem Solver
  • 227 replies
  • February 20, 2023

@Christian Hauggaard  The workaround works for me, but I think that this error must be fixed.


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