Everything Else
R9043: Helix Server and Internal Tracking of Client Support Structure

Known Problem

The Problem

When a Client is disconnected due to inactivity, the Server’s internal support structure for closed forms remain.


When a Helix Client opens a view containing a list, whether a direct list or a subform, Helix Server compiles a list the records that meet the query criteria for the list. (No query means all records meet the criteria.) This internal list is referred to as a ‘LST object’, and is stored on the Server to optimize the situation where the user scrolls the view from page to page, or closes then reopens the view before a data change would cause a change to the set of records that appear on the list.

In these situations, Helix Server uses the existing LST to gather the records to be displayed and, in the case of a view that is closed and reopened, saving time by not needing to recompute the query involved.

When a Client ‘Leaves’ or ‘Quits’ gracefully, Helix Server disposes of every LST it had compiled for that Client.

However, a problem occurs when a Client disconnects ‘ungracefully’ — either through an idle time disconnect, a crash, a network failure, or other unusual situation. In these scenarios, the Server disposes of the stored LSTs for forms that were open when the disconnect occurred, but LSTs for closed forms cannot be identified and are not removed.


Close and reopen the collection with Helix Server, RADE, or Engine: the orphaned LSTs are disposed of when a collection is opened.


This situation exists in most versions of Helix Server, in one form or another.


Open issue