I thought this would be a simple task. It almost seemed possible that a couple of simple index additions would just 'trickle down' into the update like MOST other things do.

That failing, calling a stored procedure for a little housekeeping during the install seemed a good alternative. A section in the SYSUPGRADE %PROCESS% record labeled EXECUTE PROCEDURES seems to be provided for this purpose.

Nice try. Execute a procedure WHERE? The outdated source code is the only documentation I can find on this, and it indicates that a CALL statement is used. "Call" is expecting to execute code already in the repository, and any code contained in the update will not be put there until AFTER the %PROCESS% list is finished.

Can I get there from here? Perhaps in this instance Create_Index can be called a few times with parameters hardcoded into this script… I will try that.

My question is… How do others handle such seemingly simple tasks? I know some have their own RDK replacements, but that is not the answer I am looking for. At least not today.

I am fully prepared for a ridiculously simple solution that I should know already… so go ahead and humiliate me with one. It wouldn't be the first time.

Ok… Don Bakke explained that the RDK should have magically propagated the index change with no need for intervention. (Thanks, Don!) More precisely DICT.MFS on the target table should have done it as the updated dict column was installed.

Indeed, the RDK did just what it should have in this instance, as field 6 of the target dict item is flagged for an index. I suspect there is still some vestige of Arev 2.01 still in there… but I can track it down.

Back to the heart of my original question though… Does the ability to run a little bit of code from inside an RDK update to do housekeeping on a runtime work?

I suspect it does, but I haven't by either cleverness, dogged persistence, or dumb luck been able to figure out syntax that works yet. Where is the code expected to be located, how should it be referenced, and can parameters be passed? The old RDKModuleInstall source just has a 'Call @iLine' in that location.

If it DOESN'T work, that would be good to know also so I can stop trying.

Thanks!

Indexes seem to me a bit of a problem area with the RDK, as supplied in OI.

If you install an index on dev copy, control info is put into the dict record and into the ! file.

If the dict item exists in the deployed runtime, then just running CREATE_INDEX via RDK's procedure execute will do the whole job without any need to recopy the dict item.

If the dict item doesn't exist in the deployed runtime then there is a problem as the RDK's procedure execute happens before the record copying. You can't run CREATE_INDEX until the dict record has been created!

The way round this with the standard RDK is via %PROCESS% to use first the UPDATE ROWS to copy the dict item and then to run CREATE_INDEX. It may be important that the dict item doesn't have the index controls in it as, when the CREATE_INDEX is run, it may think the index is already installed.

If you do anything natty re attaching files, you may need to think also about the updating of the DBT file (or not).

You may detect from my vagueness that we don't do this sort of thing in quite this way! However, I don't think I can help any more here than to suggest that you may need to use a bit of ingenuity!

Maybe others more learned than myself will have more and/or better advice for you.

Do we happen to know the correct syntax for the EXECUTE_PROCEDURES section of the %PROCESS% record?

For example, if I wanted to execute Rename_Table… Would I use the same syntax as I would in a Basic program:

EXECUTE_PROCEDURES

RENAME_TABLE ("OLDNAME", "DBNAME", "NEWNAME","0","0")

…or possibly like above but without parenthesis?

I haven't actually tried with the Rename_Table subroutine, but everything else including a simple MSG ("HELLO"), or MSG HELLO or MSG "HELLO" generates a load error instead of executing something.

I am thinking it is expecting to execute object code located in other than the usual location, or else I just do not understand how %PROCESS% lines are parsed in this section.

I also think the RDK is probably capable of much more than we sometimes give it credit for, if we only understood it a little better.

Jim,

Richard Bright has some of the most experience with the RDK so hopefully he'll chime in. One way (perhaps the only way) to do what you want is to do the following:

1. Write a subroutine that does all of the programmatic calls for you. Let's say you call it TEST.

2. Then create your RDK Deployment as you normally would. However, don't use the Repository View to add TEST to the deployment.

3. Attach the SYSUPGRADE table from the RDK folder.

4. Use the COPY_ROW command to copy the object code from SYSOBJ into SYSUPGRADE.

4. Open the %PROCESS% record.

5. Add the following:

      UPDATE ROWS
      SYSOBJ/$TEST

      EXECUTE PROCEDURES
      TEST

6. Save the record and test the RDK on a target system.

As you had noted, the regular entities in the SYSUPGRADE table get copied to OI after the %PROCESS% record is processed. This is why you can't call a routine that is added in the normal way (unless it already exists). The above command forces the object code to copy into the target SYSOBJ table first and then it executes it.

I think this is the only way to use the RDK to execute any commands in any meaningful way, especially since there really is no way to pass in your own parameters directly. By wrapping this in your own simple routine (e.g. TEST) you work around the problem.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don's method and sample code looks good to me.

The RDKInstall proceedure can be set up to do tasks such as install a proceedure on the target system, auto-execute to do a task, then remove itself from the system. In this vein, the RDKInstall can be used to do housekeeping such as removing entities that have become unwanted or orphaned as part of the application development.

If you dont like the RDKInstall structure, you can write your own replacement that can be called by the RDKInstall - so there is not much that cant be accomplished.

At present the RDKExtract toolset does not expose the full functionality of the RDKInstall system - you need to review the RDK docs, the source code and the RDK equates.

As a cautionary, I understand the compiled RDK code is different from the earlier source code, needless to say the structures and methods seem to be well respected.

Richard Bright

BrightIdeas New Zealand

r.Bright@ark.co.nz

Ahh… Silly me expecting the call to accept a parameter. I guess Msg("Hello") was a poor choice to test the syntax, wasn't it.

You are correct, by being able to execute a little code during the install most anything can be accomplished that needs accomplished. It will take care of my needs at least.

Thanks to both of you.

Now… with a little cut and paste and editing, those clear and concise explanations would be a very useful white paper that could save others alot of needless frustration. Maybe even a short paragraph for the RDK's docs.

Thanks for the help!

Ah, I think your've got it, but if you do want some more info, just send me an email.

Richard Bright

BrightIdeas New Zealand

r.bright@ark.co.nz

View this thread on the Works forum...