I got enough work done that I thought it was about time to experiment with a deployment. Bad move.

I see the RDK is not perfect.

First issue that's really giving me fits: I attempted a full deployment. My tables have a long history going back to ARev 1.16, but I thought I had the relevant ones working fine in OI, at least until I attempted to deploy. A number of the tables result in the following error message during deployment:

FS252 Error compiling protection module.

I have seen this error in the past in ARev, usually related to a bad Dict entry, I think. Unfortunately, the message indicates neither the table nor the column, so it's kind of hard to figure the problem. I had to add tables to the deployment one by one to begin to figure out which tables are causing the error. Now that I have some of the tables identified, how do I localize and fix the problem?

Thanks,

David

David,

Many of us would suggest that full deployment was wrong move - rather use the module / upgrade - this works very well.

Search other recent response on this topic.

What many of us have done is prepared a 'clean' master runtime system - using the developer exe. To this, or clone, add in the Application layer ie create the application. Copy your Application data directories across. Next run RDKInstall to add in your application. Set the application entry point and (optional) attach application tables and build the db table image. Finally swap the developer exe with the runtime engine and you are done. Theerafter, RDKInstall will handle any updates etc.

Have a look at the RDKInstall source code - will give you ideas of how to do a stack of supplementary stuff.

Prior to preparing an RDK I always do a SCAN_REP to check for problem components, resynch of stored proceedures and rebuild system indexes - just prudent housekeeping.

All sounds a lot but preparation of a master deployment system (a oncer) may take only 20 minutes. Preparing, extracting an RDK then re-importing the RDK into the runtime may be done in 5 to 15 minutes. Personally I have found the process no harder, indeed easier than AREV environment.

Richard Bright

BrightIdeas New Zealand

I just read your post more carefully. I'm with you until you say "copy your data directories across."

By this, do you mean: clone the data directories to an appropriate location, and then "Add" them into the OI clone from within the OI clone? At that point, I would have an empty application with all the tables installed. Then I could do an RDK upgrade, minus the tables, with little trouble, I guess. From that point on, though, as I modify tables in the development system, what method would I use to keep the data tables current in the "target" runtime master system?

Still confused,

David

Please forgive me if this ends up being a duplicate post, but one of my two other responses to your post did not seem to make it up to the site.

When you say to create a "clean" development system, how do you mean? Is this by doing a second OI clean install on the same computer (an idea which would normally make me nervous), or do you mean by cloning the active development system, and then cleaning it out?

Thanks,

David

Data directories - In OI I have always followed a policy of keeping application data in subdirectories ie MyAppSys (for general application tables, code tables etc) and MyAppData for app data. I avoid having anything in Datavol (which ends up in the root directory).

Yes.

Uptill recently I had problems with the RDK interface and data. Like you I wanted to update data dictionaries, and occassionally data. Now if you look at the RDK subroutines you will see that -

1. You can get any dictionaries and data transfered via the SDK very easily using the SYSUPGRADE table. That is do your standard RDK extract to get the commponents. Then re-attach the just-created deployment folder (which contains the table SYSUPGRADE). Now copy into that table dictionaries or data in form "AppTableName/RecordKey". For example the NAME record in DICT.MYTABLE becomes "DICT.MYTABLE/NAME". This is a right pain to do mannually but I just modified a Copy_Row form so that I select from dropdown the table, then records and these are then copied across into SYSUPGRADE in appropriate form.

Likewise I can add in, or update any Stored proceedure without re-running the RDK Extract again.

2. Want to run a proceedure, delete records, add tables, carry out maintenance etc. This is all provided for by appropriate inserts in the SYSUPGRADE %PROCESS% record.

Sorry if this is a rather verbose and pedestrian explanation.

The RDK Tools have recently been improved so some of what I have mentioned above may nolonger need to be done manually - but one tends to stick to ones comfort zone.

Again, doo have a look at the RDKInstall subroutines (and equates). Once you trace these thru you will realise that you can do all sorts of things just by plugging stuff into SYSUPGRADE and the %PROCESS%.

Richard Bright

BrightIdeas New Zealand

The biggest single PITA in OI is that it doesn't stamp dictionary elements the way AREV did/does. So, I cheat a little.

1. I do all my dict changes in AREV 3.x so the dict elements get stamped. You can actually do the changes in OI, but I sufficiently dislike Table Builder (past experiences with trashed dictionaries, etc.), that I tend to use AREV because it's easier. I wish there was a clone of DICT for OI (Sprezz has one, if I remember correctly).

2. When I'm making an upgrade, I take a pass through the DICTs of all the tables in the app looking for items that have changed since MM/DD/YYYY. Then I do a process similar to yours (reading the SYSUPGRADE table and adding the necessary DICT elements.

I have never liked the way that a full deployment works in the RDK either .. I think most of us agree on that and use the same procedure that you, Don Bakke and others use (I have a virgin system to deploy into). After that point the RDK_MODULE_INSTALL process seems to work just fine.

Don Miller

C3 Inc.

Either way will work just fine. The difference between a run-time and a development copy is just OINSIGHT.EXE (the engine). If you use REPORTER, then you need to have a copy of the .RUN version of that to rename. Also, if you're deploying an app that uses REPORTER, make sure to include a copy of the OINSIGHT setup too. There are a couple of .DLL's that need to be setup properly. Ditto if you're using OIPI, too.

Don

The difference between a run-time and a development copy is OENGINE.EXE.

- O -

Oystein ..

how right you are …

Don

Richard,

Thank you for the guidance, which is neither verbose nor pedestrian!

I guess it means I need to do some work, but I am sure your pointers have saved me hours.

David

David,

Sorry, I missed this response - others have already covered it but ..

Yes

This is the simplest way. I just copy eveything in the revboot directory across to my 'OI32run' directory, copy across the BMPS, ICONS, and whatever other essentual folders.

Next I fire up OI and delete ALL applications, one after another. This gets rid of all source code and compiled code, any junk. Also make sure that there is nothing in the DATAVOL - else your shipping junk with your runtime. At some stage remove any non- runtime executables from the 'master clean runtime' - but still keep using the Oengine.exe (Developer).

Now for an application, clone this runtime master, open up and create the (empty) application. Copy the application data subdirectories as subdirectories of this system. Run RDKInstall and set Application entry point (Application Properties) and attach tables and rebuild dbimage (Database Manager). Only step left is to swap the Oengine.exe (full) with the Oengine.exe (run).

This runtime application can now be rolled into an installshield package, simply zipped up / imaged to CD or whatever. Typically if I'm doing the install I zip up onto CD plus add to CD a ClientInstall. Then I can unzip onto the client's server (no problems of re-setting read-write file properties from CD) and then run Client Install on each w/s.

Two other comments.

1. Build a simple form, callable from your application which allows Client to locate\set path for RDK updates, and run RDKInstall. (You can do this from within Installshield - much better but more work initially). I email updates to clients and they can do updates without any fuss.

2. I have no utilities in the SYSPROG application layer, TOOLS Application which contains my shipable generic utilities, and then my Application set to inherit from the TOOLS Application. That is, the deployed system has maximum of three application layers SYSPROG, TOOLS,MYApplication.

Richard Bright

We need to get Mike to see if this could be enabled. Mike what about it?

Richard Bright

We're in the process of revamping this particular tool- you can probably see it in Las Vegas, maybe Sydney.

Mike

Excellent! Have to count up my airpoints and make my bookings!

Thanks. Richard

View this thread on the Works forum...