A couple of weeks ago, I had another interesting situation raised by Sivakumar Venkataraman. In this scenario, we had a custom Dexterity dictionary installed on a customer’s system. This customisation contained a table definition for a temporary table. To support some additional functionality, the temporary table needed an extra index added. Installing the updated chunk on the customer’s system failed to add the new index to the table definition. Running the code generated errors about an invalid index.
Siva’s first check was to look at the Resource Descriptions to see if the index was showing there. It was not showing. It was at this stage that he caught me online via messenger. I mentioned that he needed to delete the OLFD*.dat and OLFD*.idx files from the Data folder. These ctree tables are created by the Resource Descriptions windows and are populated the first time each dictionary product is selected. If changes are made to dictionary resources after the tables have been populated for that dictionary, the changes will not be shown. Deleting these files, forces them to be recreated and re-populated with the updated resource information. After deleting the files and re-populating the Resource Descriptions, the temporary table in the dictionary still did not have the added index.
So my next question was to confirm that the .CNK file had actually been extracted and was not still sitting in the application folder. A chunk file can fail to extract if the version and build information stored on the chunk file is less than the version and build information currently installed. A chunk can also fail to install if the dictionary is marked as read-only. Another reason could be if the chunk file had the wrong launch file name specified when it was creaeted. This last situation can be avoided by using a macro to create the chunk, once the chunking process is correct, it will stay correct. On the newer operating systems with UAC (User Access Control) it might be necessary to use “Run as Administrator” to have the appropriate permissions to be able to extract the chunk file.
In our case, the chunk file was being deleted after being extracted, so we needed to look for another cause.
My next thought was whether there were custom forms and reports dictionaries for the customisation. There don’t have to be modified forms or reports, but if the Modifier or Report Writer has been used with the custom application, all the base resources get copied from the application dictionary to the custom forms or reports dictionaries. The system will then use the base resources from the custom dictionaries in preference to the resources in the application dictionary. Base resources include datatypes, fields, tables, formats, messages and strings. Bingo! There was a custom forms dictionary for the product. Renaming the dictionary allowed our code to work. Deleting the OLFD files again then showed the additional index.
So, the lesson learned here is to check for custom forms and report dictionaries. If they exist, export the customisations as packages so they can be imported back. If any formats, strings or messages have been edited, you would need to make those changes again. I suggest recording macros so they can be remade easily.
Please see the following articles for more information:
- Sivakumar Venkataraman (Siva): Deploying Chunk Files – A Note to Remember
- Vaidy Mohan: How to tackle Chunk Upgrade with Modified Forms/Reports?
Hope this information helps you … one day.