Obnoxious Form Behavior--Has anyone seen this sort of design caching before?

I have a form that is driving me crazy.

The form is made up of a series of subforms. I have made changes to one of the fields in the subform that is a computed field that does a translation of data from a hidden field.

I took this formula:

@Replace(@Word(AttendeeData;“#”;4);“0”:“1”:“3”;“No Response”:“Accepted”:“Declined”)

and changed it with this:

@Word(AttendeeData;“#”;4)

but instead of the field showing the non replaced values, it is showing the “No Response” string from the @Replace formula.

My question is this–is this is because the computed field retains that formula even if I change it in the form? Would I need to re-create my document to see the change?

Also, does anyone know a way to refresh the field values without putting the form into edit mode? I tried to write an onLoad event that would put the document into edit mode and refresh the values, but it got stuck in a loop because the onLoad event ran about 10 times in the debugger (which also made no sense to me, because I figued that Onload would run ONCE–when the document loaded.)

Is all of this strange beahvior because I am using subforms? I have been beating my head against this all morning and it’s starting to cheese me off.

Any help would be greatly appreciated.

brandt

Subject: Obnoxious Form Behavior–Has anyone seen this sort of design caching before?

I have learned the hard way while doing new development, test your form with new data documents, not old existing data in your database.

The queryopen event should refresh your fields or add code in the queryopen event to put the document into edit mode, refresh it and then throw it back into read mode - kind of a hack but it should work.

If you must refresh the formula values in some old data / documents, create an agent that will apply your new formulas to those fields.

I have seen some very strange caching issues but not like yours. If it is a true caching issue, I have ended up deleting the cache.ndk file and restaring notes, this sometimes helps as well as compacting the workspace.

Subject: RE: Obnoxious Form Behavior–Has anyone seen this sort of design caching before?

After your design changes you will need to write an agent to ViewRefreshAllDocs and run it on them all.

New docs created with the new form will work right.

Old one will not auto refresh themselves.

You can use canned actions to make a quick and easy update -refresh agent. I would steer away from queryopens because thats assuming all old documents will be opened at some point and then updated…if they are being seen from a view context they will still have the old data etc,

Just run an agent on old docs and all new docs entered will have the right values.

Subject: Don’t use ViewRefreshAllDocs

I would stay away from using ViewRefreshAllDocs - this will update all the documents in the database whether they need updating or not - causing large replication times to users in the field.

Putting your update code in the queryopen obviously will not update existing documents which is why I mentioned you might need an agent - it is not assuming existing documents will be open - additionally, the requirement to show the new values in a view was not communicated by Brandt so it might not be necessary to even code and update agent.

The preferred method would be to code your update agent so it only affects the documents it needs to.

A simple SELECT and FIELD formula can accomplish this, something like:

SELECT Form = “Only the docs you want to modify”;

FIELD FieldName1 := Your New Formula1;

FIELD FieldName2 := Your New Formula2

Subject: RE: Don’t use ViewRefreshAllDocs

The solution I came up with was to create an action hotspot that only appears if the document needs a refresh. When the user clicks the action, it opens the document, refreshes it and saves it so that the changes are evident in the UI.

Thanks for the advice.

brandt