I have a table in my Application layer which is based on a view from DSA.
The table in Applicaiton layer is a write-back from PBI App where certain columns have data from existing tables and others are empty so that Power App can write to these.
Whenever i make a change in my view, the table in Application becomes red.
I have tested the following senarios and both times i needed to Deploy and Execute to get rid of the red color and star at the end:
Senario 1:
Made a minor change in VIEW:
From: Select column1 as A from table1
to
Select column2 as A from table1
I kept the alias but change the column.
Senario 2:
Wrote a few comments
Now the issue is, i cant Deploy and Execute because then it wont keep the last changes written from PBI App. I need to just Execute or just save so that it wont be overritten/initialized.
Is there a way to only Execute when changes dont impact the table structure in Applicatons?
you are running into this because you now how two directors in your orchestra: TX and PBI. If you change the structure of your view in DSA you will see that TimeXtender marks the table(s) that you map the view to as dirty. In some cases you may be able to do Deploy > Review tasks which gets TX to scan the objects and this may remove the dirty mark.
If you have changed the structure, that means the mapping has changed (mapping changes are immediate) and you require a deploy. If I have a table that is written to (or modified otherwise) by another tool, I store that table in a separate DB and take that as a source into my solution. This way I do not run into the situation where a required deploy wipes data.
An alternative is to store the valid data in a temp table, do the deploy, write it back to the valid table. This will only work if you are not using advanced features that deal with hashing (incremental, history, etc) without more effort than it is worth.
you are running into this because you now how two directors in your orchestra: TX and PBI. If you change the structure of your view in DSA you will see that TimeXtender marks the table(s) that you map the view to as dirty. In some cases you may be able to do Deploy > Review tasks which gets TX to scan the objects and this may remove the dirty mark.
If you have changed the structure, that means the mapping has changed (mapping changes are immediate) and you require a deploy. If I have a table that is written to (or modified otherwise) by another tool, I store that table in a separate DB and take that as a source into my solution. This way I do not run into the situation where a required deploy wipes data.
An alternative is to store the valid data in a temp table, do the deploy, write it back to the valid table. This will only work if you are not using advanced features that deal with hashing (incremental, history, etc) without more effort than it is worth.
the answer depends on the table settings: if your table is historical (type 1 is enough) the valid table will be preserved. If your table is incremental, the same. You do need to be careful with deploys on historical tables a bit: deploy structure changes first, change history settings later. If you have a regular table, a deploy will wipe the table.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
