Object variable not set Error in Preferences/Calendar Profile

When saving some changes to the CalendarProfile, in other words called as Preferences, you may get the following error message repeatedly sometime after opening it / sometime after click the OK button to save the changes.

This happens usually in the mail-in applications.
Object variable not set
On Module: CLICK
On Line: 32
On Method: CLICK

When you reopen the document, you find that changes are lost. None of those are saved.
Even the signature, if you update any, are missing.

Thus this issue results in data loss.
This error is recently found in two of my friend's application.

The Notes Admin guy had upgraded the application from R7 to R8.
Thus, you may think it happened because of the version change.
Or there must be some problem with the template / form's code.

However, the solution reveals that it's not a notes development issue.
The issue would even show if the version is R7 template.

After debugging the form's code and it's Script libraries; it's found that the script is looking for the person's name in the ACL as an individual entry i.e. as Owner of the application.
Logically only Owner should make any changes to the Preferences, not just everyone.
Now, if there are no Owners of the applications and everyone/anyone tries to update the preferences, they it should not show the changes. And that's what it does in this case.

If you are trying to debug the issue and you add your name in ACL individually, apart from the Group entry, and then save the changes it would save the data. And the error message would not show.

After the same is done for those two applications and it worked.
Just make sure every application has its Owner assigned in the ACL. So, that when the owner tries to update the preferences document, he would not get any error message and would not escalate the issue.

http://www-10.lotus.com/ldd/nd8forum.nsf/4b9931b774db788c85256bf0006b5e6d/d41e903c42b2c93a852577bb0048a59f?OpenDocument

Field is too large - 01

Problem Description

Error Encountered: “Field is too large (32K) or View’s column & selection formulas are too large”

Problem Scenario:

You have recently deployed some of your changes and suddenly every document gets locked. You can’t edit any existing documents or save a new document. When you close or open any document you get the following error:

You can’t do anything with the database. You check in your test copy and everything works perfectly fine there. You check the production copy’s data size and it is not too much to trigger the error. This error doesn’t let anyone to make any changes to the database.

Problem Solution

Solution:

Step 1: Find out the Form name from the document properties which when opened/edited/saved/closed throws the error.

Step 2: Find out how many hidden Text fields are present in the Form/Subform that you found out in the Step 1. These hidden fields usually have some look up code which is used in the other Listbox field of the form. Some time these Text fields if are doing look up of more than it’s maximum limit i.e. 32K then it would throw the exception that field too large.

Step 3: Now, you have to find out which are the field(s) that have the look up code in their Default Value option. E.g. say field name is schMainCompList and the lookup formula used is:

LookupList:= @Unique(@Trim(@DbColumn("":"nocache"; ""; "LUCSCEntityName"; 1)));
@If(@IsError(LookupList) | LookupList = "“; "“; LookupList : schMainCompExtra)

Every time the document is opened/edited/saved/closed the field does a lookup as the form is getting refreshed; thus triggering the error.

Step 4: Change the code to the following:


@If( @IsNewDoc | @IsDocBeingEdited;
               @Do(LookupList:= @Unique(@Trim(@DbColumn;"":"nocache"; ""; "LUCSCEntityName"; 1)));
               @If(@IsError(LookupList) | LookupList = ""; ""; LookupList : schMainCompExtra));
"")

Now this would let the field to do the look up only when the edited and not when they are opened/saved/closed.

Step 5: Now, change the field type to Listbox and check the option Allow multiple values as shown below.

Step 6: Sometime, making the code change till Step 5 resolves the issue. But the issue may still re-occur after some other time. May be this time with some other form name but with the same subform, may be. Thus, to avoid this issue further, add the @DbLookup(…) code to the Formula Window of the field properties:

This completely resolves the issue of 32K exception triggered by the hidden text fields.

In short: Check if Text field > Change to Listbox > Place the @DbLookup code in Formula Window > Use proper validation.