BI.Populate leverages %PopulateUtils to generate sample data efficiently, but does so based on some knowledge of how %PopulateUtils works internally. Specifically, it pre-sets a temporary global ID in the BI.Populate:UpdateIdCache() method, to be picked up in %PopulateUtils:BuildValueSetSQL(). However, the name of the global used for this purpose changed from ^CacheTemp to ^IRIS.Temp on IRIS and apparently this code has not changed, leading to a error downstream in BuildValueSetSQL() in certain but not all sequences of events. A customer experienced one failure scenario when running the script in a brand-new community edition container, which I was able to reproduce in a simple docker build sequence as well.
As this repo is meant for use with IRIS (Caché still has the prebuilt namespace), there's no need to conditionalize the global reference based on the product version string.
BI.Populate leverages %PopulateUtils to generate sample data efficiently, but does so based on some knowledge of how %PopulateUtils works internally. Specifically, it pre-sets a temporary global ID in the BI.Populate:UpdateIdCache() method, to be picked up in %PopulateUtils:BuildValueSetSQL(). However, the name of the global used for this purpose changed from ^CacheTemp to ^IRIS.Temp on IRIS and apparently this code has not changed, leading to a error downstream in BuildValueSetSQL() in certain but not all sequences of events. A customer experienced one failure scenario when running the script in a brand-new community edition container, which I was able to reproduce in a simple docker build sequence as well.
As this repo is meant for use with IRIS (Caché still has the prebuilt namespace), there's no need to conditionalize the global reference based on the product version string.