OpenInsight 10 Alpha – The Conversion Process

If “when will OpenInsight 10 be ready?” is the most common question we get asked, then “what will be different in OpenInsight 10?” (or some variation) definitely comes in second. To help our curious readers, we will once again attempt to answer this question by exploring OpenInsight 10 from a practical, or “need to know”, perspective. One rather important detail worth sharing up front is that all attendees of this year’s Revelation Software User’s Conference received a flash drive containing an alpha version of OpenInsight 10. This allows us to share information based on the presentations and hands-on experience with this very early release of the product. One last item before I move on: please do not ask for a copy of OpenInsight 10! This copy is meant only for conference attendees. (Editor’s Note: As noted in the comments, shortly after this article went to press Revelation Software made OpenInsight 10 Alpha available to all WORKS subscribers.)

We thought our first article in this series should focus upon what every OpenInsight developer will need to experience in order to test their applications in OpenInsight 10: the conversion process. Note, this is a conversion process, not an upgrade process. OpenInsight developers are quite used to running upgrades (after backing up of course!) in situ, i.e., against the current OpenInsight application. OpenInsight 10, on the other hand, will need to be installed into an empty folder. From here the conversion tools will be launched. This is very analogous to the ARev32 conversion process – including the way reports are generated that inform the developer what was completed and what items need further attention.

Revelation Software has reported that OpenInsight applications from version 4.0.2 on up can be converted. That is welcome news for those who have been avoiding an upgrade to version 9.x due to the cumbersome process of running multiple upgrade installers and installing various patches. The minimum requirements for running OpenInsight 10 include: Windows 7 or higher, 4 GB RAM, 2 GHz processor, and 1360 x 768 resolution.

As with any conversion process, there are steps that the developer should consider doing in order to make this process as smooth as possible. Revelation Software recommends the following:

• Remove applications that are no longer needed. OpenInsight 10 will not automatically convert all of your applications, but this will avoid confusion and unintentional conversions.
• Migrate developer created entities in SYSPROG manually. This would include most custom MFS routines, user-defined conversions, and any utilities that are intended to be inherited by all applications. The conversion process will not convert the SYSPROG application.
• Form controls named IMAGE or IMAGELIST should be renamed. OpenInsight 10 has now reserved these names for its own purposes. Failure to do this in advance will cause the form to be skipped over and added to the conversion error report.
• Application raster graphics (e.g., BMP, PNG, JPG) should be set to 96 DPI. This is important for the new DPI awareness and scaling capabilities of OpenInsight 10.
• Run the SCAN_REP tool. A clean repository is a happy repository!

The conversion process itself will modify certain entity types so they can take advantage of the enhanced capabilities of OpenInsight 10. The nature of these enhancements will be discussed in other articles, but what is important to note is that the conversion process itself will not modify the original application. Therefore, it is safe to run multiple times (which might be necessary…as documented below).

Early in the conversion process, the developer will need to make a critical decision concerning the application data tables. There are three options:

1. Move the data tables. This option will use OS commands to move the data tables into the same relative path that they previously existed in.
2. Leave alone. That is, do nothing. The developer will assume responsibility for making sure the tables are accessible to OpenInsight 10.
3. Copy. Choosing this option offers two more choices: OS Copy or LH Copy. The OS Copy option is self-explanatory. The copied data tables will be the same as the originals. If the LH Copy option is picked, OpenInsight 10 will copy the data tables using the new Linear Hash copy utilities. These will analyze and optimize the tables automatically.

The data table migration process leads to a catch-22 scenario for the complete conversion process. In order for data-bound entities, such as forms, to recompile successfully, the dictionaries need to be attached. Hence, if the tables have not already been attached then data-bound forms will fail to recompile and will appear on the conversion error report. Therefore, it might be necessary to run the conversion process at least twice. Once to manage the data tables and again to convert the entities that failed due to dictionaries being unavailable.

I experienced a variation of this during one of my attempts to convert an application. The data table copy process failed because it was unable to compile an MFS that was local to the application. However, I could not migrate this MFS over manually because the application did not yet exist. The only way around this was to remove the MFS in the original application, allow the conversion utility to copy the table, and then add the MFS back after the application was converted.

During his OpenInsight 10 Conversion Process presentation, Mike Ruane indicated that changes to the application’s DBT file are still under consideration. At issue are any absolute paths which have been moved or copied into a different path. Should these be left alone or should an attempt be made to update them? Attendees were invited to offer comments. It seemed the majority of the responses were to give developers the choice to pick either one.

In additional to application entities, the following items will also be converted:

• All SYSREPOS entities
• SYSAPP settings
• Environment settings
• Users and User Information

User migration requires some special attention. Due to the enhanced capabilities of the OpenInsight Authentication Module (OAM), all users will have passwords added to them if they did not exist before. All users, whether a password previously existed or not, will be prompted to change their password at the next login.

This last part is quite relevant, especially if the conversion process aborts for some reason. When preparing for his presentation, Andrew McAuley from Sprezzatura discovered the hard way that an incomplete conversion process makes it quite difficult, if not impossible, to log into the application. This is because user credentials are now stored in an encrypted format and the salt used to decrypt this information is stored separately. If the conversion process is interrupted, this could lead to user credentials which are impossible for OpenInsight to access. Furthermore, the old “backdoor” method of replacing the OS files for the SYSENV table is no longer possible. From a security standpoint this is a very good thing!

It should be obvious that converting applications will require some care and attention to details. It is difficult to give a qualified impression of the experience because the alpha release has several known areas that need improvement. Revelation Software has indicated that these are known to them and should be addressed in forthcoming updates. We hope to present a follow-up article that revisits the conversion process once the tool has matured and is closer to release-candidate status.