Pulling the Rug from Beneath your Feet

Many software applications are designed to self-update. With the use of the RDKInstall function, OpenInsight applications have an easy way to add this ability. Some of our own applications that we have built make use of TIMER events, remote servers, and OECGI to make this an automated and seamless feature.

One of the dangers of self-updating tools is when the tool itself is updated in a way that prevents further self-updates (say that five times fast.) I have personally seen this happen on a number of mainstream systems. The solution always results in some kind of manual update to the self-updating technology so that it can begin to work as intended.

The Runtime Deployment Kit (RDK) attempts to avert this problem in an interesting way. When an extraction is made from a Deployment Definition, one of the entities that is placed in the SYSUPGRADE table is the %RUN% record. This is nothing more than a copy of $RDKMODULEINSTALL from the SYSOBJ system table. When the RDKInstall function is ran, it copies %RUN% into the target SYSOBJ table as $RDKMODULEINSTALL.

Thus, by first copying in and updating $RDKMODULEINSTALL, the local OpenInsight is assured that it is running the same version of the RDK logic that was used to create the deployment files in the first place. Similarly, if the local $RDKMODULEINSTALL object record was ever corrupted or deleted, a subsequent installation of an RDK will remedy that problem immediately.

This concept has immediate appeal and sensibility. In theory, one can create a deployment using one version of OpenInsight and safely install it into another. Well…almost. This all works as expected until Revelation introduces another argument to the RDKModuleInstall stored procedure, which has happened. Older versions only had two arguments: installFromDir and InstallToDir. In more recent versions of OpenInsight the DisplayUpgradeLog argument was added.

At first blush this should not be a problem, right? After all, the RDKInstall function copies in %RUN% from SYSUPGRADE, making it the RDKModuleInstall that will be used. New arguments like DisplayUpgradeLog would be present and ready to use. So what could go wrong? Well, the problem occurs when an older version of OpenInsight creates a deployment that is installed in a newer version of OpenInsight. Remember, the RDKInstall function itself does not change. Since newer versions of OpenInsight assume that RDKModuleInstall has three arguments it will attempt to call it with three arguments. However, RDKInstall already updated RDKModuleInstall with the older version that has two arguments. This results in a “too many parameters” error message:

Our commercial product installers work around this issue by including a set of deployment files keyed to each major version of OpenInsight. Our installer then queries OpenEngine for the version and unpacks the appropriate deployment files. However, for quick one-off deployments we forego building a full installer. As a result we recently ran into this problem.

Fortunately there is a quick remedy one can take if waiting for a new RDK is not ideal. Simply fire up a version of OpenInsight that matches the target system, attach the deployment tables, and then copy $RDKMODULEINSTALL from SYSOBJ into SYSUPGRADE as %RUN%. Now the RDK has the proper version of RDKModuleInstall. By the way, this is one of many reasons why we highly recommend keeping clean copies of each major version of OpenInsight handy.