Your Push obviously contains a change to the CiComponent table, which changes the table structure in some way and requires some sort of 'alter table' to be executed on the target table. Heat does not allow this, if the table has 100000 rows, or more. The change succeded on Stg, probably because the table has less rows there.
I would generally recommend to use the package mechanism for transporting changes from Stg to UAT or Prod instead of 'pushing' them.
In this case you can try to
- in HEAT Transaction Detail try to identify the change(s) to CiComponent and related changes to other tables, if any; I once increased the size of Software ID in CiComponent and made related changes in SoftwareIdentity as well
- create a new development package
- add the changes to the package
- export the package and import (apply) the package on UAT (I tend not to use OpsConsole for this)
For some reasons applying the change through a package worked for me. (Support pointed me to this)
Let me know if it works for you.
unfortunately, at the moment the push to live via packages is not practicable due to the amount of about 10000 transaction sets.
We have become aware of our failures to migrate the MasterDate after getting a clear understanding of the terms in OpsConsole.
The goal is to migrate only the modifications made in the STG and not the CI data.
We have therefore tried to transfer only the configurations, settings, translations and service requests. In doing so we get other errors that we cannot understand.
Do you have an explanation or solution?
Thank you very much
1 of 1 people found this helpful
first, I would not attempt to push anything to live. You got your UAT system for testing changes first. Trying to migrate 10000 transaction sets in one go is probably not a good idea as well.
A better idea would be to create a number of development packages, each containing changes that are in some way related to each other. I think, as the transaction sets and details are a chronological record of (pretty much) anything you did in AdminUI, you could as well build smaller packages with a subset of transaction details/sets and apply them to UAT in the right order. One way or the other, this will replay all (all!) changes you made on Stg to UAT.
I would suggest to leave out anything related to request offerings . You can use the export/import functions defined for that.
My suggestion above was to use the package mechanism to solve your 100000 rows issue on FRS_CiComponent. The push will not try to copy CI data, it will try to change the table's metadata, and as Heat thinks this could be time-consuming it forbids this (my interpretation).
To your second screenshot: it appears that certain tables (e..g. Audit_InventoryComponent#) have not yet been created on your target system (UAT?), and the push now tries to define or extend a grid on such a table. Did you already create InventoryComponent with auditable fields?
I can only try to give some general advice here. I would recommend you to contact your Heat implementation partner to get additional support and advice tailored to your needs .