Upgrade script are always connected

  • 16 March 2023
  • 3 replies

Userlevel 4
Badge +10


With the previous version we could set an upgrade script for 1 versions. 

Now, when we write a script, and deploy a release, the script is always there. This is not necessary. We can remove it of course, but that is manual labor. 

Is this meant to be? Or a minor bug? 



3 replies

Userlevel 7
Badge +21

Hi Alex,

The upgrade script is indeed pretty much always active as when you upgrade your end product, the source model version is updated to be equal to the model version that has been rolled out on the database. Even without any changes, the upgrade script is active as the source model version equals the one on the end product.

There should not be any harm in upgrading your end product every time. We also automatically upgrade our end product Software Factory every night due to this.

Feel free to create an Idea to expand the Upgrade script checks in a way that it only gets active when it's really needed 😄

Userlevel 4
Badge +10

Hi Mark, 

Reading my question back I see it’s unclear. Yes, the upgrade is not a problem. 

What I mean is, the Functionalities with an UPGRADE code group. 

This code is also executed every time we create a deployment package. And usually we only use this for removing values when changes Elements, for example. So, we do this once. and everything is ok. 
No need to do this everytime. 

Hopefully this explains it a bit better. 


Userlevel 7
Badge +21

Hi Alex, 

I get it, the assignments of Upgrade control procedures 😄

You can assign these Control procedures in two ways:

  • Always, meaning every Upgrade you do the control procedure template code will be weaved into the Upgrade code file
  • From a specific model version, meaning when the source version of the branch is set to this model version, the control procedure template code will be weaved into the Upgrade code file (2023.1) - (2022.2 and before = from project version to project version)
    The program object looks like one of the following:
    • ug_before_upgrade_from_XXXX
    • ug_during_upgrade_from_XXXX
    • ug_after_upgrade_from_XXXX

(XXXX = model version name)

This does require the model version to Use upgrade logic. This can be enabled for any created model versions with the prerequisite that the model version has a name (model version description). 

Model overview > Branches > Model versions

Hope this helps!