A bullet is dodged...

8 August 2003--It began on July 31st and ended, in practical terms, August 6th. Barely a week from isolation to resolution. We dodged a bullet. As vigilant as we are about not raising expectations unnecessarily (read this if it hasn’t been repeated often enough), we did, clearly, let one slip by and had to fix it. We were fortunate that it only took such a relatively short time. Perhaps our implementation of paid services had at least part of its desired effect; i.e., to give us the time to deal effectively with a crisis. It’s too early to say. Who knows if we can resolve the next crisis as quickly.

A year ago tonight we urged you to fasten your seat belts. A year later, we have two releases of Helix under our belts, more than a year of experience at this job and a moment to assess our progress and look down the road a bit.

In the next few weeks, you’ll read about how Helix 5 will be transformed into Helix 6 and 7. We’ll talk about the path we’ve chosen and why we believe it is The Right Way(™) to move Helix into the future.

In spite of this detour, we are still on plan. While it will take longer, as far as what day we get it goes, it won’t take more time. As we get closer to Helix 6, we’ll want to come back to this crisis every now and then to remind us of how easily a trip like this can unravel and why we have to handle them just like this next time. Here, then, presented for posterity, is the posting we made Wednesday, announcing the resolution of the so-called "5.2 Fixed Point Bug."

Helix Alert:

5.2 Fixed Point patches are available now: Download now.

2003.08.06--On 31 July, we reported that a serious bug had been identified with the expanded Fixed Point field in Helix 5.2. We are extremely pleased to report that intensive efforts to isolate this behavior have been successful and that you can now download a patch program that will update your copy of Helix and correct the bug. We strongly urge all users of Helix 5.2 to download and apply this patch immediately.

Our investigation of this problem revealed that Fixed Point data gets corrupted after a crash, when the data entered since the last successful "Save" operation is being read into the collection from its Logfile.

The data in the logfile is not corrupt, but when it loads back into Helix, the corruption occurs. Thus, if you are logging, and your Helix system crashes, stop and download the patch immediately. Remember: It is critically important that you NOT relaunch Helix before you apply this patch to your Helix application. If you allow Helix to apply the logfile, you will experience corruption of any modified fixed point field data in records that are updated.

Finally, note that if you are not logging, you are in no danger whatsoever. This is a rare exception to Helix wisdom. Please don’t take this information as an endorsement of that practice. Logging is one of the most important reasons we use Helix.

Here is the accurate information regarding the various hypotheses we posted earlier:

• Corrupted fields are easily identified, as they contain a number that is outside the legal range for fixed point numbers. It is displayed as +/-92,233,720,368,547,760.
  Correction: Corrupted fields are not necessarily easily identifed. They will either be the number shown above or as zero (0)
• The updated field’s old data is irretrievably lost. This is not a case of faulty display. The record data stored in the collection has literally been replaced with bad data.
  This information is (unfortunately) correct.
• The problem appears to be limited to records that were created in a prior version of Helix. New records are not affected.
  Correction: Any fixed point field data that was modifed via the application will be corrupted when the logfile is applied.
• The problem appears to only happen when the values are updated via posting. Both increment/decrement and insert posting have been demonstrated to exhibit this bug.
  Correction: Any fixed point field data that was modifed via the application will be corrupted when the logfile is applied.
• In an indexed list, the affected fields will appear in the range of 0 to -1, typically right between the two, but sometimes interspersed with the zeros.
  This information is correct.

Important things to keep in mind:

• If you are not using Fixed Point fields, you will not be affected by this problem.
• If you are not using logging, you will not be affected by this problem.
• If you do not crash while logging, you will not be affected by this bug.
• If you do crash, bear in mind that if you decide--for whatever reason--to allow that logfile to post, you will have corruption.
• If you do crash, and you stop the logfile from posting by means of a command-period, all the data in that logfile will be lost.
• If you have purchased 5.2 but not yet upgraded your collections, please do not do so until you apply this patch.

How do I know if there are Fixed Point fields in my collection?

From the File menu, select Export Collection Details and open that file with a text editor. Search for "Fixed Point."

Another solution is simply to open your Relations and select "View by Kind" from the "Icon" menu. Once in that view mode, locate your fields (by clicking the Field icon in the palette on the left side of the window; doing this will select your first field) and observe the "Contents" column. The words "Fixed Point" will appear there if you have such formatted fields in your collection.

5.2.1 is coming

Version 5.2.1, which will include this fix along with a handful of other minor fixes, will be released after a hopefully brief round of beta testing. Watch the Helix 5.2 page for details.5.2.1 become the current release of Helix once it is released, replacing 5.2. Naturally, anyone who already owns 5.2 will be entitled to a free upgrade.