5
As far as I know there is no way of actually deleting a table/field/key marked as ObsoleteState = Removed.
So in the life span of our App, we'll keep adding to waste if we need to change table structures. We'll have tables like:
- MyTable (app version 1.0.0.0)
- MyTable2 (app version 1.0.0.1)
- MyTable3 (app version 1.0.0.2)
- MyTable4 (app version 1.0.0.3)
...where we when we change the datastructure for new versions write upgrade code to move data from i.e. MyTable3 to MyTable4. After the upgrade is run, there is no real reason to keep MyTable, MyTable2 and MyTable3 around and they are typically marked ObsoleteState = Removed.
But why can we not delete them in the next version (ie. app version 1.0.0.4)?
It would be nice to be able to cleanup and as far as I can see the only real problem here is that you would not be able to upgrade from i.e. 1.0.0.0 to 1.0.0.4 - you'll have to upgrade to 1.0.0.3 first. That could easily be checked and an appropriate message could be shown in the upgrade codeunit.
If a app lives in 10 years and go through many changes in data structures, the number of obsolete tables will be unmanageable - and the upgrade code will be unmanageable too… Even Microsoft has back in time reused tables IDs in the base app and required upgrades to go through other versions to handle data changes.
So in the life span of our App, we'll keep adding to waste if we need to change table structures. We'll have tables like:
- MyTable (app version 1.0.0.0)
- MyTable2 (app version 1.0.0.1)
- MyTable3 (app version 1.0.0.2)
- MyTable4 (app version 1.0.0.3)
...where we when we change the datastructure for new versions write upgrade code to move data from i.e. MyTable3 to MyTable4. After the upgrade is run, there is no real reason to keep MyTable, MyTable2 and MyTable3 around and they are typically marked ObsoleteState = Removed.
But why can we not delete them in the next version (ie. app version 1.0.0.4)?
It would be nice to be able to cleanup and as far as I can see the only real problem here is that you would not be able to upgrade from i.e. 1.0.0.0 to 1.0.0.4 - you'll have to upgrade to 1.0.0.3 first. That could easily be checked and an appropriate message could be shown in the upgrade codeunit.
If a app lives in 10 years and go through many changes in data structures, the number of obsolete tables will be unmanageable - and the upgrade code will be unmanageable too… Even Microsoft has back in time reused tables IDs in the base app and required upgrades to go through other versions to handle data changes.
STATUS DETAILS
Needs Votes
Business Central Team (administrator)