Notes/Domino Fix List
SPR # KHIA6GQ8V4Fixed in 7.0.1; 6.5.6 releaseRegression in 6.0.5



Product Area: Designer Technical Area: Design Platform: Cross Platform

Lotus Customer Support APAR: LO10596

SPR# KHIA6GQ8V4 - In formula language, assigning a rich text field to itself caused the field to be corrupted. The formula engine normally checks to see if a value being assigned in the same as the value already in the field. If it is, it doesn't perform the assignment. This was not being done for rich text fields. This regression was introduced in 6.0.5.

Technote Number: 1223584

Problem:
When you attempt to open certain documents, the Lotus Notes® client crashes.
Documents that can be opened may have Rich Text data that is truncated at the
bottom of the field. If the Rich Text field (RTF) contains a table, Notes may
crash if you attempt to modify the table. In some cases, a Notes crash may
occur if you attempt to open a section or modify an element within a Rich Text
field.

Fatal Thread
nnotesws.DeleteBundle
nnotesws._BundleEvent
nnotesws._HotSpotRunEvent
nnotesws._DocDispatchRABEvent
nnotesws._DocDeleteHotSpot
nnotesws._HotSpotEnd
nnotesws._DocFixupRABs
nnotesws.@DocLoadRecords
nnotesws.@DocLoad
nnotesws.PartialNoteAvailable


Additionally, if you attempt to access an attachment contained in a Rich Text
field the following error will appear:
"Note item not found"

This issue occurs in cases where a Rich Text field has been populated, using
either the @SetField function or the FIELD statement, based on a source Rich
Text field containing multiple items at the document level. In this scenario,
only the first item of the source field is placed into the target field. In
cases where attachments were originally present in the document, this will
result in the loss of that data; the $File items are removed during the
process. If the field contained sections or tables, for example, they might
not contain the necessary internal closing/end entries. Thus, when Notes
attempts to render or modify these elements the crash occurs. This crash issue
was reported to Quality Engineering as SPR# CBAR648FKK and has been fixed in
Notes 7.0.

It is not expected that using @SetField or FIELD to set a Rich Text field to
its own value should fail in this manner (truncating all but the first item).
This particular issue was reported to Quality Engineering as SPR# KHIA6GQ8V4,
and was fixed in Notes/Domino 6.5.6 and 7.0.1.

Excerpt from the Lotus Notes and Lotus Domino Release 7.0.1 MR fix list
(available at http://www.ibm.com/developerworks/lotus):

Design
Regression in 6.0.5
SPR# KHIA6GQ8V4 - In formula language, assigning a Rich Text field to itself
caused the field to be corrupted. The formula engine normally checks to see if
a value being assigned in the same as the value already in the field. If it is,
it doesn't perform the assignment. This was not being done for Rich Text fields.

In the case where an attachment has been removed the data is not recoverable
via Notes/Domino. Backup restoration is the only possible way to recover the
missing files.

Prior releases of Notes/Domino did not allow one to populate a Rich Text field
based on another Rich Text field's value when using the @SetField function or
the FIELD statement. The behavior of earlier Notes/Domino releases was similar
where only the first item of the source Rich Text field was populated in the
target Rich Text field. There are no plans to address the issue.

Note: In some releases of Notes, doclinks and view links may appear as database
links. For information on this topic, refer to the document titled "Viewlinks
and doclinks are copied as database links when using @SetField or FIELD to set
a Rich Text field's value" (#1222426).

Workaround
When setting a computed field to its own value, you should simply indicate its
field name. In other formulas avoid using FIELD and @SetField unnecessarily
(see the note below).

For example, the following construction will delete the Body field
conditionally:

FIELD Body := @If(Ret ; @DeleteField ; Body);

The problem with the above formula is that when the False condition executes,
the formula evaluates to the problematic: FIELD Body := Body;

Instead, the following formula could be used:

@If(Ret; @SetField("Body";@DeleteField); @Return("") );

Note: Formulas that make use of @SetField often are preceded by a FIELD
statement to initialize the field that is set in the @SetField function. For
example: Field X:=X; @SetField("X"; "text"). This construction is not
necessary in all cases. It is necessary only in Field formulas that use
@SetField to set the value of a field that is above or to the left of the Field
formula containing the function call. The construction is not necessary in
agents or Field formulas that use @SetField to set the value of a field to the
right or below the current field.



Determining which databases have been affected by the loss of attachments:
A utility has been written which can be used to help identify documents in a
database that are missing file attachments. These attachments have icons
listed in Rich Text fields, but have no corresponding $File field containing
the attachment.

Note: This utility makes no distinction between fields that exist on the form
and those that do not. A document may contain a Rich Text field that does not
exist in any form, and it could possibly have a problem attachment even though
users will never see the missing attachment's icon in the document. For this
reason, the output includes the current form value for the document so as to
allow the ability to evaluate the severity of the problem being reported. It
is possible that the utility will find problem attachments that are actually
insignificant. For example, a document could possibly contain a problem field
incorrectly and no user would ever report the error. It is the customer's
responsibility to sort out the files and documents reported by this utility to
ensure that each reported problem is significant.

Usage:
FindLostFiles [database] [options]

Available options are:
-? Print help page
-S output results on a single line per missing file
-M output results in multi-line human readable format
-D output results in semi-colon delimited format

Output:
FindLostFiles version 2.0 Feb 17 2006

Processing all data notes in database .\widgets.nsf
Scanning all rich text fields
Found 976 documents to process...
WARNING! Missing File: NoteID=0x227E; Filename=document1.doc; Field=body;
Form=FormA, UNID=213A52EC:4D9CD191-C1256FC7:00392F75, Last Modified=02/01/2006
04:01:20 AM EDT, Updated By=Joe User/ACMECompany
...
Found 24 total notes with missing files
Found 32 total missing files.
Finished running FindLostFiles.


Alternatively, the output may be formatted into multi-line or semi-colon
delimited.

Multiline:

WARNING! Note 0x227E has a missing file 'document1.doc'
Field: body
Form: FormA
UNID: 213A52EC:4D9CD191-C1256FC7:00392F75
Last Modified: 02/01/2006 04:01:20 AM EDT
Updated By: Joe User/ACMECompany

Semi-colon delimited:

WARNING! Missing File: NoteID=0x227E; Filename=document1.doc; Field=body;
Form=FormA, UNID=213A52EC:4D9CD191-C1256FC7:00392F75, Last Modified=02/01/2006
04:01:20 AM EDT, Updated By=Joe User/ACMECompany


The utility has been compiled for Microsoft® Windows® and AIX. IBM® Lotus®
Technical Support cannot provide further assistance with this utility or
customizations to the utility.

W32


AIX


Supporting Information

The formulas listed below demonstrate some basic formula examples that will
result in truncated Rich Text fields when the field Body has multiple items.

Either of these results in the field Body being impacted:

- FIELD Body := Body;
- @SetField("Body"; Body)

Either of these results in the field RTF being impacted:

- FIELD RTF := Body;
- @SetField("RTF"; Body)


Note: There is an unrelated crash issue which can occur when performing basic
operations after pasting a section into a Rich Text field. This stack observed
in the Fatal Thread may appear similar to the one discussed in this technote,
with the exception that it will start with the call: nnotesws._ToggleBundle.
For more information on this issue, refer to the document titled "Notes crash
occurs when performing Save or other basic operations after pasting a section"
(#1224014).
More >



Last Modified on 12/08/2013

Go back