Everything Else
Helix 8.0.1 Release Notes Companion TLWs: Build 6343Build 6350

These release notes describe bug fixes and other improvements in Helix 8.0.1. Please read them carefully.

These release notes are divided into four sections: New/Improved Features, Fixes for bugs found in Helix 8.0, Fixes for bugs found in Helix 7 and later, and Fixes for bugs found in Helix 6.2.4 and earlier. You can click the section titles to show or hide each section.

Release Dates:
Build 6343: November 3, 2020
Build 6350: May 4, 2021

Important Notes

Helix 8.0.1 is not compatible with macOS 10.15 (Catalina) or later.
Helix 8.0.1 requires macOS 10.6–10.14; macOS 10.9–10.14 is recommended.

Helix 8.0.1 is backwards compatible with Helix 8.0, but not with Helix 7.0.4 or earlier. Helix Client users should not update until the Helix Servers they connect to have been updated.

What’s New in Helix 8.0.1


64-bit conversion of Client/Server network protocols

The messages passed between Helix Server and Client are now 64-bit compatible. This in itself does not make Helix 64-bit ready, but it is a large step forward.

64-bit conversion of popup menu code.

The code that builds popup menus (dynamic and static menus, Quick Query and Sort Order popups, etc.) is now 64-bit compatible. This affects Helix RADE, Client, and Engine.

64-bit conversion of change record processing.

The messages that are sent within Helix when a record is changed (replaced) are now 64-bit compatible. These are, for example, the messages that tell a list view to redraw when data is replaced on an entry view. This affects Helix RADE, Client, and Engine.


Improve performance redrawing lists due to data changes

When programming, one makes assumptions about the conditions upon which this code will be called. Over the years this code aged: Open Transport was retired, the QuickDraw drawing model was changed in macOS, cooperative multitasking went away with Carbon events. Change record processing was not ignored along the way, but faster machines and networking undid the delicate balance of assumptions it was relying upon.

The final result of our internal test case deleting 9997 records was reduced from 34 minutes to 20 minutes with Client and Server on the same machine. We can not categorically state that the scale of that improvement will be that good over standard LAN or WAN, but situations where Clients are updating open windows should definitely be faster, with less network traffic as well.

Final note: A dynamic popup menu is, technically, a list and should be similarly affected. but as most popups do not — and should not — contain thousands of records, the improvement may not be measurable.

Note: As this improvement required a substantial rework of the way in which adding, deleting, and replacing records is processed, a deeper understanding of this change is warranted, so that network administrators can be aware of potential issues that remain at large. For Helix RADE and Engine, list redrawing would typically happen in a background window after data entry is done in the front window. In Helix Client it could be the same, or it could simply be an open list on one Client that is redrawn by a data change made by another Client. Queried lists should be watched carefully, particularly if the data entry is done while the query is still in the process of building the list. In this regard, it is important to distinguish the period in which a search is working its way through the process of gathering records (the busy wheel is displayed) from the time it takes to subsequently display these gathered records on the screen (the checkerboard pattern appears over records that have not yet been drawn). Although we do not expect any problems to be found, a case where data is changed while an opening window is displaying the busy wheel — before it changes to the checkerboard — that results in a partial or incorrect data shown on the list should be reported to QSA ToolWorks immediately.

Open Damaged Collection Bypass Added

The ability to bypass some cleanup routines (HO_Mend) was added, allowing a collection that has a damaged view to open rather than exit with a 5xxx or 7xxx error on launch.

This added capability does not repair the collection — that’s what the cleanup routine was trying to do — and chances are the collection will still crash with minimal effort. But at least the collection will open so that details can be extracted that enable repairs to be made.

To bypass the cleanup routine, hold Shift + Option when OK’ing the User Authentication dialog (or when opening the collection, if there are one or fewer users).

Note: holding just the Option key down when OK’ing the User Authentication dialog in Helix RADE opens the collection in Design Mode (if the user has Design Mode access) while closing all windows left open except the main collection window. In Helix Engine (and RADE for users without Design Mode access) holding the Option key down closes all windows left open in the last session. In Helix Client it reloads the structure from the Server, effectively reseting it the the state specified by the collection designer, (losing all custom window positions and queries in the process).

Bugs Fixed in Helix 8.0.1

All Products

Eliminate hangs when redrawing a list in the background

In the course of moving to 64-bit, multiple bugs in change record processing were found and fixed. These bugs could result in hangs in prior versions that could not be reproduced. These were timing dependent hangs which are more likely in Client/Server on a LAN than over the Internet.

Running Client and Server on the same machine exacerbated these timing issues, as macOS sends TCP/IP packets process to process and doesn’t even count them as network traffic.

The bugs that were fixed should result in fewer cases of Helix hanging when a list is open in the background and a record is replaced that causes the list to redraw.

Data change records are now processed from session log after a crash

During the process of converting change records to 64-bit, it was discovered that Helix Server was not processing data change records that occurred when restoring the session log after a crash. This appears to be a long standing problem that goes back at least as far as Helix 6.0, and possibly further.

One potential issue with this bug would be the case of fragile indexes that need to be invalidated by the data entries failing to do so. This would, of course, be corrected the first time a user entered a record that would also invalidate the fragile index, but there would have been a window of time immediately after a crash recovery where the index would be wrong. This is now fixed.

Apple event errors retrieving data (R9555)

In the legacy data suite, both the retrieve records as list and retrieve records as string actions contained two distinct bugs that would occur when a record being retrieved from a view that posts on export (i.e. on retrieve) could not completed the posting action due to a write lock or other issue:

  1. The error number was not being returned, leaving the script (and its programmer) with no way of knowing what had gone wrong.
  2. The internal process ID that was opened was not closed, causing the Server to lose one slot until the administrator canceled it from the UI.

Both of these issues are fixed and now return the correct error code, e.g. 270 (AEGetRow): Locking problem with posting target record.

Client/Server Only: Changing data now triggers rebuild of dependent fragile indexes (R7480)

When data that is used in a fragile index is modified, the index should be invalidated and marked for rebuilding. This has always worked in RADE and Engine, but for many years it has not worked in Client/Server. This is now fixed.

When a fragile index becomes invalid, any open window that is reliant upon that index now closes — as it used to do when this feature worked correctly (before this bug appeared). Reopening the window can result in a delay while the index is fully rebuilt. (If the delay is more than a second or two, the concept of fragile indexes is being abused by the collection, and this should serve as an ongoing reminder that a redesign is needed.)

Starting with build 6350, Helix Client displays a dialog during index rebuild, but since Client does not know how long Server will take to complete the rebuild, an indeterminate progress thermometer is displayed. (Technically, this dialog is displayed anytime a view is opened. This is expected to be refined in a future release.)

Helix Server does not display a thermometer during index rebuild: the activity is displayed on the splash screen.

The following minor bug fixes were also implemented…
  1. An extra parameter is now passed to the error message dialog to help understand why some users report incorrect Why? messages.
  2. Improve error message when Session Data Log can not be applied.
  3. Improve text in the Helix Utility sdef.
  4. Fix typos in the Helix sdef.