The RDK is supposed to be able to deploy a developer's changes, which can then be installed into a production system. As I've described in another thread, that doesn't seem to work for me. (It looked like it was working a few days ago, but as I noted in the other thread, when I tried it again today it didn't work.)

The problem is related to dictionaries–evrything else deploys & installs without a hitch. It is clear from the other thread that I am not the only one who has had problems with this. On the other hand, it can't possibly be true that everyone has this much trouble deploying an upgrade, or surely Revelation would have fixed the problems a long time ago.

So I am wondering if there are other ways to deploy that are more reliable. Should I use APPBACKUP instead of the RDK? Should I try doing a check out? Or do these methods have the same problem with tables?

Also, I believe it is supposed to be possible to deploy tables manually, although I couldn't get that to work, perhaps due to my own mistakes.

Or maybe most people don't do upgrades? I could try a full deployment instead. The problem then would be how to get the client's data tables into the deployed system. Maybe just copy the files at the operating system level? That would be rather tedious, as there are a number of database tables, but it could turn out to be a lot better than struggling with upgrade deployments.

Or are there people who manage to do upgrade deployments with the RDK? I'm always wondering if there is some kind of corruption in the client's production database that is making this task much more difficult than it should be.

Thanks in advance for any advice. Actually, I haven't come to the end of the road yet with the RDK–there are still things I could try–but if there is a better way, please let me know!

Cliff

In my experience, dictionary items can occasionally be a bit stubborn.

I have found that if I use the System Editor to open a similar dictionary item from SYSREPOS, and then Save As the record to the new dictionary id, (changing the date last updated field if necessary), then the dictionary item will deploy successfully.

Hope that helps

Robert Lee

Hi,

Thanks for the response.

] I have found that if I use the System Editor to

] open a similar dictionary item from SYSREPOS,

Do you mean in the production system, before attempting to run RDKInstall?

] and then Save As the record to the new dictionary id,

] (changing the date last updated field if necessary),

] then the dictionary item will deploy successfully.

In effect, you are creating a new dictionary, that will be replaced by the deployed dictionary; is that right? So this would apply only when deploying a brand new dictionary and not when upgrading an existing dictionary? Or have I misunderstood?

BTW, do you end up having different filenames for the dictionaries in the production and development systems? Do you care if the filenames are different?

Thanks,

Cliff

Cliff

]Do you mean in the production system, before attempting to run RDKInstall?

I mean in the development system prior to deploying an upgrade or application.

]In effect, you are creating a new dictionary…

In effect, I am creating a new entry in the Repository which appears to be missing, which is why the dictionary ITEM is not deploying. I am not talking about a whole dictionary or a whole table. I am talking about adding new field / column to an existing dictionary / table.

For example, suppose I have a table called CLIENTS, and I want a new field in that table called GENERAL_NOTES, but I can't get GENERAL_NOTES to deploy:

I go into the System Editor, open a record, choose a table called SYSREPOS. A list of rows is displayed on the right hand side. I choose a similar dictionary item - say MYAPP*DBCOLUMNCLIENTS.GENERAL_NOTES. The SYSREPOS record for CLIENTS.GENERAL_NOTES is displayed. I then go File, Save As MYAPP*DBCOLUMNCLIENTS.REMINDER_NOTES.

Field 5 contains a list of associated entities which I normally remove. Field 25 contains the date this entry was last updated. If necessary, can change this date so it is after the date you use in the "Entities changed since…" option in the deployment. Don't forget to resave any changes and …

After this, the dictionary item deploys and installs perfectly.

If my recollections are correct, SCAN_REP doesn't look for missing repository entries and create them as necessary, which would eliminate the need for this.

Robert Lee

Hi Robert,

Thanks very much for the extra details, and my apologies for my delay in replying. Actually, I'm not sure if this is the problem I'm having. I think that the tables are deploying correctly, but not installing correctly. In my other thread on deployment, it was suggested that I remove the extension from my directory name, which I did, and the RDKInstall then worked. I thought the problem was solved, but when I tried it again later, I couldn't get the install to work again. If the install works even one time in hundred, I suppose it follows that the deployment must be OK. Well, not necessarily. There could be something flaky in the deployment that causes the install to fail most of the time, I suppose. But if the columns were not deployed at all, I don't suppose the install could have worked even once.

] For example, suppose I have a table called CLIENTS, and I want a

] new field in that table called GENERAL_NOTES, but I can't get

] GENERAL_NOTES to deploy:

I think you mean an old field called GENERAL_NOTES and a new field called REMINDER_NOTES?

] I go into the System Editor, open a record, choose a table called

] SYSREPOS. A list of rows is displayed on the right hand side.

You're lucky. I get the error message "Too many keys to display. Truncating…", then I get a partial list of rows.

] I choose a similar dictionary item - say

] MYAPP*DBCOLUMNCLIENTS.GENERAL_NOTES. The SYSREPOS record for ] CLIENTS.GENERAL_NOTES is displayed. I then go File, Save As ] MYAPP*DBCOLUMNCLIENTS.REMINDER_NOTES.

I don't have any "DBCOLUMN" entries in the list. I tried typing in a couple using the syntax you've shown, but they aren't to be found in my SYSREPOS. I also checked out the SYSCOLUMNS table, and all the new columns from my table are listed there.

] Field 5 contains a list of associated entities which I normally

] remove. Field 25 contains the date this entry was last updated. If ] necessary, can change this date so it is after the date you use in

] the "Entities changed since…" option in the deployment. Don't

] forget to resave any changes and …

Is there any danger in fiddling around with this table? I suppose it wouldn't hurt to back up the system first.

It is quite possible that I haven't fully understood your response, but to me it looks like the problem you've had is different from the problem I'm having.

Many thanks for taking the time to reply to my question.

Hi Cliff

]I think you mean an old field called GENERAL_NOTES and a new field called REMINDER_NOTES?

Yup.

]You're lucky. I get the error message "Too many keys to display. Truncating…", then I get a partial list of rows

Yup. I get that too. You can still type in the row id you want though.

]I don't have any "DBCOLUMN" entries in the list. I tried typing in a couple using the syntax you've shown, but they aren't to be found in my SYSREPOS

I wonder if that is your problem. From the main Open Insight for WorkGroups screen, click on File, Application Properties, and you will probably find "Maintain Database Columns in the Repository" is not clicked. Click it, then it will add the database columns into the repository.

Of course you are welcome to take a backup prior to doing this…

In answer to your original question about whether RDK is the way to go. I would say YES, YES YES. It has worked very well for some time. One technique we use is to deploy a program with each upgrade which gets called after every upgrade is installed. This program can do all kinds of housekeeping duties including copying new tables (including dictionaries) into the destination system, upgrade notes for the end users, etc., etc.

Say you deploy your upgrade to C:\UPGRADE. You can then use COPY_TABLE to copy a new table to that folder (with a modified name). The housekeeping program can then ATTACH_TABLE to the upgrade folder, and copy the new table into the destination system. If you want to install an empty table, with only the dictionary, you can use CLEAR_TABLE either when copying the table to C:\UPGRADE or within the housekeeping program. If you do this, then you will also need to ATTACH_TABLE to the destination data folder, and then use DEFINE_DATABASE to save the new Database Definition.

Hope that all makes some sense…

Robert Lee

] I wonder if that is your problem. From the main Open Insight for

] WorkGroups screen, click on File, Application Properties, and you

] will probably find "Maintain Database Columns in the Repository" is

] not clicked. Click it, then it will add the database columns into

] the repository.

You are right, it's not clicked. At one point I found a mention of this in the discussion group, from a few years ago, so I wasn't sure if it still applied. I clicked the option and tried deploying again, but it still didn't work. Maybe I should leave the option clicked, though, while experimenting with things like the Barry Stevens' version of RDKInstall.

] In answer to your original question about whether RDK is the way to

] go. I would say YES, YES YES. It has worked very well for some

] time. One technique we use is to deploy a program with each upgrade

] which gets called after every upgrade is installed. This program

] can do all kinds of housekeeping duties including copying new

] tables (including dictionaries) into the destination system,

] upgrade notes for the end users, etc., etc.

] Say you deploy your upgrade to C:\UPGRADE. You can then use

] COPY_TABLE to copy a new table to that folder (with a modified

] name). The housekeeping program can then ATTACH_TABLE to the

] upgrade folder, and copy the new table into the destination system.

] If you want to install an empty table, with only the dictionary,

] you can use CLEAR_TABLE either when copying the table to C:\UPGRADE

] or within the housekeeping program. If you do this, then you will

] also need to ATTACH_TABLE to the destination data folder, and then

] use DEFINE_DATABASE to save the new Database Definition.

] Hope that all makes some sense…

Yes it does. Thank you very much for some excellent tips!

View this thread on the forum...