Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 07 APR 1999 06:49:30AM Glenn Bryant wrote:

In my development directory, I added a new term to the dictionary of a file called CLOSED_DAY_SALES. Then I deployed an upgrade. In the newly created upgrade directory is a file named DICT.CLOSED_DAY_SALES. It contains the new term as well as all of the other dictionary words. When I apply the upgrade to my runtime, using RDKINSTALL, the new dictionary item does NOT get applied to the file. If any kind of log is created in RDKINSTALL for errors, I don't know how to find it. No errors are displayed. Any help will be appreciated. Thanks glenn bryant


At 07 APR 1999 04:13PM Stephen Revelation wrote:

Glenn,

I've run into a similar problem in the past. I tried repeatedly to deploy with no luck when I hadn't had this problem in the past. It turned out that my copy of OI became corrupt as I deployed on a fresh copy of OI and had no problems.

Stephen Revelation


At 07 APR 1999 09:40PM Glenn Bryant wrote:

It turned out that my copy of OI became corrupt as I deployed on a fresh copy of OI and had no problems.

Stephen, I'm unsure what this means or what you are asking me to do. But I have just deployed my first production copy of my app in the last week and really need to get it updated.


At 07 APR 1999 11:09PM dsig@teleport.com wrote:

I am not sure I understand your reply .. but

1) if you create a dictionary item it should get deployed .. yes? If yes then there is a BUG in the repository process.

2) how can OI become corrupted when OI is self contained?

dsig@teleport.com onmouseover=window.status=imagine … ;return(true)"

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080


At 08 APR 1999 11:29AM Stephen Revelation wrote:

Glenn,

I'm sorry if I wasn't clear yesterday. Perhaps at one time when I performed the SCAN_REP form executable on my old copy of OI I may have removed some necessary entities.

What I did to fix my problem was to install a fresh copy of OI to another location and use the APPBACKUP form executable to bring my application to the new copy of OI. Then I redeployed again, upgraded the application again with a new dictionary table, and then deployed an upgrade. This time when I ran RDKInstall the dictionary and other changes were evident.

This was my workaround. Let me know if this helps and in the meantime I'll look into this further.

Stephen Revelation


At 08 APR 1999 03:33PM Stephen Revelation wrote:

Glenn,

BTW, which version of OI are you using?

Stephen Revelation


At 08 APR 1999 04:41PM Cameron Purdy wrote:

Hi Glenn,

1. Is the create table instruction for the table and the dictionary in the %PROCESS% record of the SYSUPGRADE table for the RDK-created upgrade? (I could not tell for sure whether the dictionary was getting created by the upgrade. Is it? Is the problem that the dictionary is created but no items copied into it?)

2. Are the dictionary items in the SYSUPGRADE table? They would have keys starting with "DICT.CLOSED_DAY_SALES/". If they are not in SYSUPGRADE, they will not get copied into the new dictionary, assuming question 1 above is that the empty dictionary is successfully created in the runtime application. If this is the case, just copy all the items from your DICT.CLOSED_DAY_SALES table into SYSUPGRADE, remembering to rename them to be prefixed by "DICT.CLOSED_DAY_SALES/".

Cameron Purdy

Revelation Software


At 09 APR 1999 07:03AM Glenn Bryant wrote:

Cameron, in response to yours:

1. In the %process% record are:

  COPY TABLES
  .\DATA/BIT_REPORTS/PARTS
  .\DATA/DICT.CLOSED_DAY_SALES

as well as a whole bunch of other instructions. The table CLOSED_DAY_SALES is the one whose dictionary I had added a symbolic to, the symbolic is in the table DICT.CLOSED_DAY_SALES in the UPGRADE directory, BUT the symbolic does not get added to the dictionary of the user table in the runtime directory. I.E., the table already existed, all I want to do is to add one item to its dictionary.

2. They are not in the sysupgrade table - why is that? SYSUPGRADE consists of %module%, %process% and %run% and then 390+ rows beginning with SYS, which are my SPs, popups, events windows etc. In the upgrade directory there are all of the dictionaries that I told it to include in the upgrade.

I am running OI3.7. Cameron, my goal when I create an upgrade is to include ALL of my entities all of the time. If I create a new script, new program (sorry, stored procedure), new form or just a new help message or anything else, I want that entity to be picked up and added to the upgrade. Is that not possible? Thanks Glenn


At 09 APR 1999 07:10AM Glenn Bryant wrote:

Stephen, I and my development system are in Virginia. My deployed runtime system is in upstate Indiana. I don't really have the option of re-deploying, since the user has been on it for two weeks and has been adding lots of info to it. So I gotta upgrade. This is OI 3.7 BTW. Glenn


At 09 APR 1999 08:57AM Cameron Purdy wrote:

Glenn,

The table CLOSED_DAY_SALES is the one whose dictionary I had added a symbolic to, the symbolic is in the table DICT.CLOSED_DAY_SALES in the UPGRADE directory, BUT the symbolic does not get added to the dictionary of the user table in the runtime directory. I.E., the table already existed, all I want to do is to add one item to its dictionary.

I'm not a pro with the RDK so forgive me while I give you manual (as in "by hand", not "RTFM") instructions and explanation. You want to deploy one dictionary item, which is one record, so to do that the record MUST BE IN SYSUPGRADE and MUST BE NAMED TABLE/KEY to be deployed. That is all.

So attach SYSUPGRADE.

Then copy the dictionary row:

run Copy_Row "DICT.CLOSED_DAY_SALES", "X", "SYSUPGRADE", "DICT.CLOSED_DAY_SALES/X"

Get rid of that copy table instruction for the dictionary.

Cameron Purdy

Revelation Software

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/1b81bf6cb9d783208525674c003b76d7.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1