After the initial installation we are going to be changing various dictionary items and then our customers will need those changes. We are curious how others do this. How do you keep track of what dictionary item changes were made? And how do you update your customers with them. AFAIK OI does not track dictionary item changes for you and in addition, the RDK does not handle dictionary item updates. (We would like to send our customers only the updated dictionary items, not full dictionaries.) How do you handle this?

Jeff,

How do you keep track of what dictionary item changes were made? And how do you update your customers with them. AFAIK OI does not track dictionary item changes for you and in addition, the RDK does not handle dictionary item updates. (We would like to send our customers only the updated dictionary items, not full dictionaries.) How do you handle this?

The Table Builder uses the C "Table API" which has a very low granularity when it comes to changes; in fact, it updates the dictionary by copying the "TEMP_" dictionary (the one actually being designed) over the actual dictionary. In 3.6 we have improved the support for deploying dictionary items, but the one thing it doesn't do automatically is tell you which dictionary items were changed since a certain time. We plan to add this feature, but because of the way the Table API is designed, the task was larger than what we could complete for 3.6.

Cameron Purdy

[email protected]

Thanks Cam.

You said "In 3.6 we have improved the support for deploying dictionary items"

Elaborate on that please. What does that mean for us?

Also, when you deploy tables - when you run RdkInstall on the customers runtime, does it replace the data portion of their table? Does it replace the dictionary portion of their table? Does it individually copy the dictionary items in over top of theirs or does it kind of dump the whole new dictionary in over top.

We are using 3.6. With the RDK it looks like you can deploy just the dictionary portion of a table (DICT.Tablename). Is that correct? This plus the answer to part 1 will be most helpful.

Jeff,

We are using 3.6. With the RDK it looks like you can deploy just the dictionary portion of a table (DICT.Tablename). Is that correct?

Yes.

You said "In 3.6 we have improved the support for deploying dictionary items". Elaborate on that please. What does that mean for us?

From the README:

Fixed upgrade/module dictionary item deployment; previously the actual dictionary records were not being deployed. (SYSENV/RDK_DEPLOYTABLES, SYSOBJ/$RDKEXTRACTOIBODY)

Related fixes:

Fixed a bug the prevented deployment indexes. (SYSPROCS/RDKEXTRACT, SYSOBJ/$RDKEXTRACT, SYSPROCS/RDKEXTRACTDATABASE, SYSOBJ/$RDKEXTRACTDATABASE, SYSPROCS/RDKEXTDATABASEINSTALLINFO, SYSOBJ/$RDKEXTDATABASEINSTALLINFO)

Fixed several problems and inconsistencies specifying tables in Module/Upgrade Deployment Definitions. The list of tables now defaults from a repository view, if used. User modifications to the list are preserved if possible as other options are modified. (SYSREPOSWINS/SYSPROGRDKDEPLOYDEF, SYSREPOSWINEXES/SYSPROGRDKDEPLOYDEF, SYSPROCS/RDKDEPLOYDEF, SYSOBJ/$RDKDEPLOYDEF, SYSPROCS/RDKDDLOADDBPROCESS, SYSOBJ/$RDKDDLOADDBPROCESS)

Does it replace the dictionary portion of their table? Does it individually copy the dictionary items in over top of theirs or does it kind of dump the whole new dictionary in over top.

Your choice … either. If you deploy the DICT table, it copies over. If you select individual DICT columns, it copies just those records.

Cameron Purdy

[email protected]

You said: "In 3.6 we have improved the support for deploying dictionary items, but the one thing it doesn't do automatically is tell you which dictionary items were changed since a certain time. We plan to add this feature, but because of the way the Table API is designed, the task was larger than what we could complete for 3.6."

This is an important part of supporting our customers and we do not have time to write our own OI subsystem to handle this. Can we count on this for 3.7?

Jeff,

This is an important part of supporting our customers and we do not have time to write our own OI subsystem to handle this. Can we count on this for 3.7?

It is planned for 3.7, but what makes me hesitate to absolutely *guarantee* its delivery is the large number of related modules that were affected when we started implementing the desired functionality. Our number one priority is to continue to increase the stability of the system.

Cameron Purdy

[email protected]

View this thread on the forum...