I would like to know, how the deployment scripts are processed and where I can track the history or status (to be run/already run) . I have an issue, that I run content of several deployment scripts directly in SQL and now I’m not able to do successful update via Architect.
The number of actual model version is saved in db_data table
After importing new model version and running command “Run update scripts” are processed sequentially (according to their numbers) all scripts, that are included in every version (/versions) with higher number (/numbers).
So you can try to run rest of scripts manually one by one (CTRL+X) and finally edit the number of version in
AsapModelVersion table according to your new version. You will need know SchemaExtensionId of the package - you can find it in Architect’s packages view: stay on it and choose menu Model/Edit item.
Caution: This operation is not standard and can have unintended consequences.
Please be careful and make backup before this operation to not lose consistency.
Thank you. I’ll try it and let you know.
It is definitely not a good practice to execute scripts by hand when deploying.
You normally run scripts one by one when adding them during development but when you are in a deployment mode, so you are loading new packages e.g. to a production server, you should always let the system run all the scripts in their order and let it update the
AsapModelVersion table accordingly.
Please what is exact order of running scripts and creating objets on deployment process?
What is driven by?
I have situation I made changes on several packages at once. Now there it is collision in some script, that wants to update non-exist object, because the sript that creates it is in another (probably lower) package.
Script Execution Order
- Scripts are first sorted by the package hierarchy. So Root comes first, etc. Lower packages ALWAYS execute first.
- In each package the scripts are executed by version number and then by order number.
These are problems you might run into.
You create a view in a lower package but you are trying to add fields in higher packages. Even though the view-entity definition is contained in a lower package, you need to move the complete ALTER view statement to the higher package where you are making the changes. Supporting this scenario is basically very difficult because e.g. if you add some more fields in the lower package, you anyway have the dependencies in the higher package so you need to create the deployment script there.
Updating old databases
Since all the scripts inside a package are executed (starting from the version you have in your database up to the latest script) it may happen, especially if you are updating a very old database, that e.g.:
- You added an entity in package1/v1
- You added a field to that entity in package2/v1
- You removed the complete entity in package1/v2
If you do the deployment in between these changes, nothing bad happens. But what happens if you update the complete database in one step?
- package1 scripts v1 and v2 get executed (creating a table and dropping it afterwards)
- package2 scripts v1 gets executed (adding a field to the table) – but the table was just dropped by running all the updates on package1.
There is no solution for this case so far other than updating in steps (loading multiple package xml files instead of loading just the current one and executing all the scripts).
Thank you, this is exacly my problem. To be complete: how is determined order of scripts in more packages on the same level?
It is not determined. Since sibling packages have nothing in common, no special sort order is set.