Hi,

I'm wanting to add a table to an existing application. In working with the RDK, in the repository view, I select the OpenInsight tables, along with other elements, but the Upgrade/Module does not copy it to the upgrade subdirectory and the %PROCESS% record is empty. I can't even find in the RDK… code where this is supposed to happen. If I try to do an Application deployment, (in ordert to deploy the table) I can not specify a view, and must use all publishable. Of course I could restrict the publishable entries to those I want for this upgrade, but with a lot of entities, this is tedious.

What am I missing?

A lot.

First, the Deployment module SHOULD be able to do this all for you (Well on the latest OI32 version I am moderately confident it does, but some time since checked). I will dig deeper if you cant crack this but…

Second, to roll your own using the RDK system - have a look at the source code for RDKModuleInstall in SYSPROG. Note the section COPYFILE$, also DELETEFILE$ if you so wish. Look also at the RDKDeploy_Equates (as found in the SYSPROCS table) - The "Upgrade records " section at the end of the equates gives you the section headings in the %PROCESS% record. Essentually all you need is the section heading in the %PROCESS% record, the appropriate data as follows:

COPY TABLES

OSDir\File\Account

Plus the table that you want to add to the target system should be copied to your volume that contains the SYSUPGRADE.

Thus when the RDKInstall runs, it copies the table in, attaches it and updates the db image. All finished.

Richard,

Thanks for the reply. I'm using the plain vanilla deployment tools, and an application deploys OK, coping tables, etc.

My issue is adding a table to an app. In the repository view, I can select OpenInsight Tables, but they never appear in sysupgrades.

I find the code in rdkextractdatabase where it copies tables that are in an application deployment, but not where it copies tables from the repository view.

I had this problem a few years ago, and solved it my using an AREV upgrade and had both OI and AREV installed at the customer site. I just did my tables upgrades with AREV and everything else with the RDK.

I was hoping by 32bit time, the issue was fixed.

I think your reply was addressing application deployment. Any more ideas on adding a table with and upgrade?

Paxton

Paxton ..

Your question and mine are the same. No problem getting stuff deployed with a New Deployment. Upgrades pose the problem for me. Since OI doesn't Date/Time stamp the changes to Dict elements, the way AREV does, it's difficult to track these changes. Therefore, during development we use AREV to do ALL dict changes and can therefore extract changes using:

SELECT DICT SOMEFILE WITH TYPE=F""S" AND WITH VOC_DATE GE "mm/dd/yy"

and copy the changes to a temporary folder to hold the changes. It's getting these changes to deploy to upgrades that has me going round in circles. The VOC_DATE symbolic lives in VOC and uses:

K=COUNT(@RECORD,@FM)+1

XX=TRIM(@RECORD) ;* date stamp in last field

DTE=XX10,99

@ANS=ICONV(DTE,'D')

This is extremely handy. But my deployed app allows the use of 2 different folders: 1 for "live" data and another for "tutorial" data. I can swap these tables on the fly at run-time just fine. The problem occurs when I have to get the deployment to do the same thing on the fly:

1. Attach the \OIDATA\CONVERT directory which contains the dict changes to be applied. This may be changed elements or NEW tables that must be migrated. It's easy enough to get the list of elements to be changed. All the tables end in _NEW. New tables contain a data portion as well. Therefore the pattern "DICT.SOMETABLE_NEW" can be processed quite easily. The problem is that I need to deploy a stored procedure ahead of the table changes and then call it during an RDKMODULEINSTALL. I think I've figured out the %PROCESS% record, although documentation would be a big plus. The problem is that it takes one pass through the list (if it's included as a file_list item and this seems to be hard coded or at least has to be manually put into the SYSUPGRADE, presumably from the Repository, although manual editing seems possible.

Anyway, there ought to be a simpler way to do this. Like you, I've used AREV to do this for most of my sites since a large number of them have migrated from DOS to Windows so AREV lives there.

Don M.

C3 Inc.

Nop. I WAS addressing application upgrade ie adding a table to an existing application via the RDK deployment system. To reiterate, just add to the %PROCESS% record the section

COPY TABLES

OSDir\File\Account

…. where OSDir=relative or absolute path to target directory on the deployed system;File=Name of Table to deploy; Account=Account in which table resides.

Now you have to add the table-to-be-deployed to the volume where the SYSUPGRADE table was created. Thus when the RDKInstall runs thru the %PROCESS% record it hits this section COPY TABLES and then processes a copy table command using the provided information - note the table is temporarily attached as part of the RDKInstall process.

Alternatively you could use the CREATE TABLE section and then put all your dict items, or data records in the SYSUPGRADE table (with appropriate key in form MyTable\MyRecordKey.

Now all of the above is the hard way. As mentioned, I'm sure we can use the RDK deployment system, but I confess that at some times it foxes me. I would have to go and play before being confident about indicating how-to-do-it. Besides I am still brain dead and in part holiday mode.

Let me know if your still struggling.

Richard Bright

BrightIdeas New Zealand

Don,

I agree with you that it would be great to have the OI Dict records date stamped similar to AREV.

* Mike - is there a reason why this was not carried thru from AREV, and why it cant be now done. What I am looking for is an easy means of identifying, listing and extracting all dict records changed since such and such date etc.**

Don, I again agree with you that the documentation on the RDKInstall stuff is somewhat less than complete. By this I mean that there is so much more that one can do beyond the RDK extract utility - which one has to dig round and explore the code to work out.

I built a little copy record utility to help me extract to SYSUPGRADE any Dict items and records that I wanted in the upgrade deployment.

Don, your problem of updating both live and tutorial seems best handled via a stored proceedure - as you currently are doing in AREV. That stored proceedure can handle all the attach_Volume and copy stuff. Just need to copy in the stored proceedure and execute it as part of the RDKInstall process, and at the end have the RDKINstall process delete the stored proceedure.

Well, Nice discussion. Yes, Stephen, I figured as a fall back I would manually copy the tables into the volume with SYSUPGRADE and put the COPY_TABLE in the process record.

But, since the repository view boxes lets me select the tables and put then into the upgrade view side, I figured it ought to work 'on its own' Oh, well. Just one of those things I've been away from for a while, and 32bit is so good, just thought this might work now too.

Thanks for your help, and reminding me of the proceedure and syntax to manually get these tables moved.

Paxton

Paxton,

Ok, you stirred me up re using RDK Extract tool.

I can confirm that the toolset DOES extract the table nicely into the folder along with SYSUPGRADE. At the same time it creates a section in the %PROCESS% record thus:

COPY TABLES

.\DATA/DICT.MY_TABLE/TOOLS

.\DATA/MY_TABLE/TOOLS

I would need to check (but at present to lazy) that the table will be deployed in the right spot. (May need to edit that 'DATA' value to that of the target volume - cause the RDK tool is not a mind-reader))

I also note that to get the table to show in the repository view (of the RDK Extract, I had to uncheck 'Published Only'. Probably because I hadnt rebuilt my repository index.

So in conclusion, in OI 4.12 the RDK Extract + the RDK_Install is good for extracting all entities including tables and updating a deployed system. The guts is that you should be able to handle pretty much all deployment upgrade jobs with these tools and a little extra knowledge and care.

Richard Bright

BrightIdeas New Zealand

View this thread on the forum...