Computed Fields Mystery

HCL Domino Domino Forum
1

I may need a psychiatrist… but let’s see what you guys say first:

A WebQuerySave agent creates a document with a code like this:

…

Set reportdoc = New NotesDocument(db)

reportdoc.Form = “Report”

[other fields populated]

…

Call reportdoc.ComputeWithForm(False, False)

Call reportdoc.Save(False, False)

The “Report” form has about 150 fields;

There are some 30 hidden fields at the bottom, most of them computed.

All used to work fine, but, as I kept adding fields at the bottom,

I noticed that those at the very end do not get computed any more.

Currently, the last 4 fields (“computed”, not “CFD”) are not being computed.

They have simple formula, like:

ResponsibleAttorney + @Text(ReportYear) + ReportPeriod

Now the best part:

These 4 fields do not show in any view,

they are not in the document properties box,

but, after “un-hiding”,

I see them with their correct values when I open the document !?

Please help… I hope it’s just my stupidity, not insanity.

Thanks,

Simeon

2

Subject: Computed Fields Mystery

Are/were these fields added thru designer or in script?

How many fields in the form?

3

Subject: RE: Computed Fields Mystery

The fields were added in Designer, not by script.There are arond 150 fields, some 30 of them computed.

Again:

I SEE the values in those fields when I open the document,

but they do not show in any view, and are not in document properties.

Thanks,

Simeon

4

Subject: RE: Computed Fields Mystery

Maybe I’m misunderstanding something here, but tell me if I’m wrong:

  • You have existing docs in your database that get generated/populated automatically, and it used to work fine.

  • Then using Designer, you added fields to the form used by those documents.

  • Now those new fields don’t have values on those documents unless you open up the docs in the client.

Do I have the gist of it right? If so, then … well, the good news at least is that there’s a simple explanation. See, adding fields to a form doesn’t automatically calculate and add the values to the existing documents. You still have to go back and populate those new fields on the old documents, either by opening up and resaving the documents manually, or with an agent (something like @Command([ToolsRefreshAllDocs]) might do the trick). Notes doesn’t just recognize the presence of a new field and automatically recompute all docs with that form for you, I’m afraid.

The reason you see the values populated when you open the documents is because the computed field formulas are kicking in and producing a value in the UI. But that value isn’t saved into the document unless you … well … save the document.

Apologies if I’m completely missing the boat here on what’s happening.

-Stephanie

5

Subject: RE: Computed Fields Mystery

Thanks Stephanie,

You patrially answered my question (as why I see these values).

I thought computed fields are being computed only when saving,

now I know this also happens when creating documents.

The real issue remains open, though.

Please read again my initial posting.

It’s not about existing documents, and I do know the difference between fields and values/items.

A new document (Report) is created by the WebQuerySave agent of another document.

If the form of the new document has, say, 120 fields, all computed fields of the new document get their values.

When I add more fields to the form, the last 4 computed fields of any consecutive NEW document have no values.

It looks like there is a limit of the number of fields to compute when programmatically creating a new document.

Thanks,

Simeon

6

Subject: RE: Computed Fields Mystery

Thanks for clarifying, I figured that seemed like too easy an answer. (You’d be surprised how many people don’t understand that distinction, though.)

Is there any difference between your new fields that don’t work and the old fields that do work? Do the “old” ones have input translation/validation formulas that the new ones don’t have, or anything like that?

The reason I’m asking is because I seem to remember something about ComputeWithForm explicitly not working on computed fields. (I avoid using it, myself, so maybe that info is out of date. Help docs seem to indicate it’s still true, though.) But it does work on translation/validation formulas… so if your other computed fields had input/validation formulas (or got set by them via the translation/validation formulas of other fields) and your new ones didn’t, that might be an explanation of why one set works and another set doesn’t.

(I know, you’re going to say there’s no difference, no translations/validations, CWF works fine on computed fields, and we’re back to square one - right? I’m curious now though and want to know why it’s happening too. :slight_smile:

Just for kicks, does it work if you change the field type of one of the new fields to “editable” and give it a default value of whatever its computed value was?

-Stephanie

7

Subject: RE: Computed Fields Mystery

No difference indeed.All my apps are for the web only, I don’t use translation/validation formula at all, only JS for this.

Sorry, this is production, so I already changed the agent to explicitly populate the fields when creating the document, so for now I’m not testing with editable + default value.

I’ll probably continue on Tuesday with some tests.

I’m confused… I know that ComputeWithForm is not supposed to compute fields (this is sort of side effect), but I’ve always used it with no problems.

Thanks again Stephanie,

Simeon

8

Subject: RE: Computed Fields Mystery

I don’t think 120 fields should be enough to trigger this, but you may have run into a limit in either the size allowed for computed fields on a given form, or the amount of fields in general. There is a living doc with what is known of these limits here: http://www.thenorth.com/northern.nsf/0/4100857248b8b82185256d350058f7e4?OpenDocument

If that’s the case, I believe you should be able to move those fields around, and the NEW last 4 fields on the form should not be saved. If that is your problem, the only solution will be to combine some data in some of those fields.

9

Subject: RE: Computed Fields Mystery

Thanks Robert,

I just checked one of those documents - it’s only 1,550 bytes.

This should be way below any limits.

Also, the actual number of fields on the form is only 108.

A workaround is not a problem,

I can explicitly populate these fields from my LS agent,

but I’m really curious why is this happening.

Thanks,

Simeon

10

Subject: Computed Fields Mystery

Hi Simeon,

a few remarks:

  • when you open a document with a form that contains computed fields that are not in the document yet, these fields are computed even in read mode… but not stored in the document. That explains at least one phaenomenon.

  • while the documentation says there is no difference between computewithform(true… and computewithform(false… I found true more reliable.

Also (just an idea) try to catch an error:

tmp := ;

@if(@isError(tmp);@text(tmp);tmp)

It could be something not available at computewithform time.

Hth

:slight_smile: stw

11

Subject: Computed Fields Mystery

On the Defaults tab of the Form properties box, is the ‘Generate HTML for all fields’ checkbox selected? If it isn’t then the values of the hidden fields will be lost when a document that uses the form is edited from the web.

12

Subject: RE: Computed Fields Mystery

Yes, ‘Generate HTML for all fields’ is checked.And - FYI - even if it’s not checked, hidden fields are not lost when saving from the web.

Thanks,

Simeon