Hello All,

I?m a bit of a dabbler with OI, but I?ve hit a stumbling block that from reading various threads may be an OI fault.

I?m using OI 3.7

I?ve written a very small application and produced a runtime.

I?ve since updated the application and I want to Upgrade it.

It doesn?t seem to want to update the dictionary.

Fortunately I?ve put a button on the window with a click event that runs:

Declare Utility()

UpgradeDir=Utility(?ChooseDir,@window?)

Call RDKInstall(UpgradeDir)

If status ?. Etc

On the development version I have created a Repository view as per instructions

I?m sending various executables and two dictionary updates

I?ve attach_table to the upgrade directory according to forum instructions and have found in %PROCESS%

COPY TABLES

.DATA\DICT.TABLENAME/APPLICATIONNAME

.DATA\DICT.OTHERTABLENAME/APPLICATIONNAME

The upgrade seems to go through ok ? the windows/form are updated, but as they relate to the new dictionary I am getting the following error:

Error running dictionary item ?NEW_DICTIONARY_FIELD_NAME?

Obviously the dictionary hasn?t updated why?

Is it me?

Is it OI?

Is there an answer?

TIA

Claude

Claude,

SRP uses the RDK for all application deployments but we don't use it for dictionary updates so this is somewhat of a guess. Have you confirmed by scanning the REVMEDIA file whether or not your dictionary files were actually copied? If so, then I suspect the problem is that you need to update the .DBT file (i.e. the Database Definition).

dbakke@srpcs.com

SRP Computer Solutions, Inc.

I've checked the files in the update directory (with both arev and oi) and the two dictionaries are there.

Sorry for my ignorance but

How do I update the .DBT file? Is it on the development version or the runtime?

The runtime I have goes straight into the user screen, will I need to have access to OI engine etc?

TIA

Claude

Claude,

There is one DBT file for each application - in the main OI folder. File name: .DBT. The app's DBT file is where OI keeps info about which tables to attach for that app.

The DBT file is a text file (sort of), but difficult to edit. The easiest way to update the DBT file is to do the "SYSPROG shuffle": First copy SYSPROG.DBT, which knows about the system tables, over the DBT file you want to update. Then start OI and your app and reattach all the app tables with Database Manager. Which means you need the development version to do it.

- Oystein -

Claude,

If you recall, on a development system you would normally Add tables using the Database Manager and then Save the database. This updates a file in your REVBOOT folder called APPNAME.DBT. This .DBT file is used by OI to attach files. Even though you can add tables to a volume, OI won't attach them unless this information has been updated to the application's .DBT file.

I'm not exactly certain how to get the RDK to do this for you. I believe the functionality is built in, but like I said, SRP does not use the RDK for table updates. I believe Revelation/Mike should know the answer to this rather quickly.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Are you adding new table or just updating some dict items.

That is to update just dict items treat them as any data so does not need section header in %PROCESS%. You can add, update and delete.

If you are creating a new table then this requires an update of the dbt image. This should happen with the RDK but I think in your version faulty RDKInstall. Need 3.73.

Richard Bright

Richard,

All I want to do is update two dictionaries.

Can it be that difficult?

Thanks

Claude

Donald,

While I'm waiting for Revelation Mike to respond, What do you at SRP do to update dictionaries?

Is there a simpler way adding some form of copy_row without the RDKInstall.

Any help/suggestions will be greatly appreciated.

Thanks

Claude

Revelation Mike? Is that like Indiana Jones?

IN looking at the source code for the RDKINstall (Which members of the CSP already have ), there is a note that the dictionary records that you want to be deployed should be copied into the SYSUPGRADE table. This will also recreate the indexes that existed in the development system.

We can probably modify the RDK tool to do that copying for you- is there a need in the community for this? We could get it out for the 3.7.5 release later this year…

Mike

Mike,

Funny you should think "Indiana Jones", one of the free cable channels just played "Raider of the Lost Ark" a couple of nights ago. It made me want to watch the whole series again.

Well I must confess to Claude that I was not paying all that much attention to his original post. My first impression was that he wanted to add a new dictionary to the runtime system. I see now that he is trying to add new dictionary columns. My apologies, Claude, for leading you down a false trail. Perhaps you'll redeem that conversation when you want to add new table/dictionaries.

Revelation Mike is correct, and you don't need to the power of the Ark of the Covenant to get this done. Here is an approach that should work:

1. Create the RDK with just your normal items.

2. Go ahead and run the Deployment process so it will create the RDK tables in an empty folder.

3. Attach this folder. You should now have access to the SYSUPGRADE table.

4. Now copy your dictionary items to SYSUPGRADE by typing RUN COPY_ROW "DICT.TABLENAME", "COLUMNNAME", "SYSUPGRADE", "DICT.TABLENAME/COLUMNNAME"

This RDK should now automatically copy your dictionary updates to the target environment.

There are a couple of slightly different approaches to the above that would be better if you plan on doing dictionary updates more regularly. First, if you check the "Maintain Database Columns in the Repository" this will create place a deployable version of your dictionary columns in the SYSCOLUMNS table. The RDK will then have a Database Columns entity type that you can select from like any other component. The other approach is to create your own entity point to your dictionary columns by copying an existing Miscellaneous/Application Rows entity and then renaming the content to refer to your dictionary column. This latter approach is more effective with rows in tables that need to be regularly deployed but there is no predefined entity type to select it from.

Let me know if this helps or if you need further clarification.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

In early days maintaining dictionary items in the repository caused no end of grief so we stopped doing it. Do you do this now? If so we presume the grief has gone?

Cheers

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...