Just curious to see how others are dealing with this situation. As many of you probably know, when a deployment is created using the RDK, a special record with the key ID %RUN% is created in the SYSUPGRADES table. This record is really just the object code for RDKModuleInstall. When the deployment is being installed in the target system, %RUN% is also copied over the existing RDKModuleInstall and then used to facilitate the loading of the current deployment.

The net effect, of course, is that target environments are getting their original RDKModuleInstall objects overrun by different versions of this program. For a long time it didn't matter (since changes were very few or were simply fixes) but now when I load a deployment (that was created in a 7.1 system) into a 7.01 (or earlier) I am getting the status log file popping up for all subsequent deployments that I create with this 7.01 system.

It's almost viral in nature…but I was never really concerned about it until now. In a controlled runtime environment (i.e. a customer is solely dependant upon a single vendor for support) this is no big deal. In a development environment where we exchange deployments with other developers this is causing some minor annoyances.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

For what its worth we have also been "bitten" by the RDKModuleInstall issue in the past. With 7.0 I made a concious decision not to make any modifications especially since they are not updateing the source code. I basically place a shell around RDKInstall and it updates our own log file etc. But no custom modifications are made to RDKModuleInstall.

The net effect is we have had to live without a couple of enhancements that we did in the past. Once such enhancement was the ability to perform a Copy_table to an evaluated path. For example, on our development system a file was located at p:\revsoft\userfoldera at the customer it needs to go on G:\xyz\userfoldera. I just edited the "%PROCESSES%" record \userfoldera/table/account. The "modified" RDKModuleInstall would search the attached folders for the first match that ended with the string after "". But alas, we now have to live without this nice enhancement as I now have to "hard code" the exact path for the customer.

HTH,

John

Don,

Glad you brought this up. I have found the log file poping up quite annoying and confusing. I seem to get some errors that I don't understand and my deployment seems to work just fine. And, since I have not learned how or implemented a method to turn it off, I am reduced to telling the customers to ignore the messages and discarding it.

Kinda ugly.

I also have some custom code to maintain my own upgrade history and fortunately this still works so I have not yet dug into this.

paxton@oihelp.com

ARCS, Inc. [img]http://www.arcscustomsoftware.com/arcslogo.gif[/img] </QUOTE> ---- === At 09 FEB 2005 10:00AM Richard Guise wrote: === <QUOTE>I found RDK facilities for updating site installations rather short of what I really wanted - so some years ago I made BIG modifications to RTI's published RDKMODULEINSTALL source code as well as "shelling it". Program mods include ability to run processes after as well as before record copying, optional update of DBT file, extra commands, =FILENAME syntax to set volume path to match site installation locations, etc. I then have an RDK editor which copies my modified program to %RUN% and adds a header file with sequence number, date, title, etc. It can also rewrite/delete any records, add records (e.g. dicts), merge two updates. It'll also print cpontents of an update for file/reference. Shell checks sequence no, keeps detailed log of update and loading info, etc. - for view via utility button I'm extending shell to do multiple RDK loads to multiple switchable databases which some users require. Lots more! Hope this gives you some ideas. That's what's great about ARev and OI that, if one wants, one can do these sorts of things! </QUOTE> ---- === At 09 FEB 2005 10:21AM Donald Bakke wrote: === <QUOTE>Richard and Revelation, I wasn't really looking for ideas on how to use the RDK. We already do very similar things. I am more concerned about the way %RUN% gets distributed and replaces $RDKModuleInstall on the target system. This technique creates problems with custom versions (such as yours) or with different versions of OI (i.e. such has deploying 7.1 into 7.0 or earlier). I guess I am looking for suggestions on a better approach. The concept of deploying our own RDKModuleInstall is attractive in that I may need my deployment to do some very unique things that may target system might not already support. However, it should be able to do this without replacing the native version of that program. Otherwise, when [i]that[/i] system creates its own deployments it is forced to send out the $RDKModuleInstall that it received from the other system. This is why I made the comment about the RDK methodology being like a virus...it just propogates itself upon contact. dbakke@srpcs.com [url=http://www.srpcs.com]SRP Computer Solutions, Inc

We handle this with a two prong approach.

For complicated installs, or other reasons we won't go into here, we have a custom installation routine that we use.

For not so complicatated installs, we handle this rather simply.

All of our upgrades are handled through a UI. So, after the UI gets the upgrade path, does its confirmations and authorisation checks and so forth, it copies the current RDKMODULEINSTALL off to a backup copy, lets the RTI code do its thing, then copies it all back.

It's not a shell, because you should have a UI for your upgrade routines, which get shipped with the initial application. This is one of the cases where we use the custom installation routine, since we can modify it ever so slightly to fir the different needs of slightly different products.

I can honestly say that we've never been caught with an RDKMODULEINSTALL problem in any deployments.

The Sprezzatura Group

World Leaders in all things RevSoft

Don

Object was not to teach people like you and Sprezz how to suck eggs!

There are clearly quite a few people out there who would benefit from the sort of mods which can be made to these things and it doesn't do any harm to put ideas into heads and to stimulate some discourse on this sort of subject.

Also, I hope RTI may just be looking and may consider product improvements along the lines of the sorts of ideas which various people mention.

Cheers

Richard

It's an interesting topic. There's really three deployment models when it comes to using RDKMODULEINSTALL.

• Deploying to indentical versions
• Deploying to earlier versions
• Deploying to later versions

Each requires different levels of handling the movement of code.

Deploying to identical versions is matter of fact and would cause no problems. The other though, bring various levels of complexity that should be considered when creating deployments.

When deploying to a later version, care needs to be taken that updated code is not overwritten by earlier code. This includes more than RDKMODULEINSTALL, but DLL definitions and other code.

When deploying to an earlier version, you also need to ensure that certain code functions are not overwritten with later versions, since they might not be compatible. For example, suppose your routine relies on a function that wasn't installed with the target version of OI, or used an opcode that does not exist in that particular engine.

There's also much more to deployment than targeting OI versions. Suppose your company ships two different utilities, and they share some common utility functions. If your IP tool is a little older, it could have a version of a utility that a few versions lower than your disk management tool. If the IP tool is installed after the disk management tool, functions that are required for the disk management tool could be removed in the "upgrade", since your common utility has now been reverted to three versions back.

There's also requirements if your application installs DLLs to ensure that it doesn't step on the toes of existing DLLs in the system, and they are registered properly. With OI now allowing OCX and OLE controls, our deployments will quickly turn into more than just copying LH files and records around.

Installations are tricky matters, and it's important to consider all the possible purmutations before jumping in and copying things onto an unknown computer.

All in all, it makes the overwritting of a simple install routine a trivial matter.

The Sprezzatura Group

World Leaders in all things RevSoft

I'm sure all this is correct - but one could go barmy with it all.

To achieve some of these one would have to set version dates and the repository would have to ensure that, on any change after a version date, the existing copy would be archived off before modification. You'd have to tell the RDK which version you were updating so that it could get the right copy. Etc, etc.!

I just try to make sure that everything is backwards compatible - usually (!) successfully. We seem to struggle along somehow!

However, sometimes one can prepare an RDK update and then find an item in it needs alteration before it's despatched. A facility to rewrite such items is very useful. Also, one sometimes wants to include something outside the repository, such as a dictionary record and it's very useful to be able to add such items. These practices might be regarded as heresy by the purists - but that ain't half useful sometimes!

Would the solution be for the RDK to compile RDKModuleInstall before it copies it to %RUN%

View this thread on the Works forum...