In a form I have field X (number, computed) that gets data (multiple values) from a view using a DBlookup (code below). I have specified NoCache (also tried ReCache), but the lookup uses a cache anyway and shows old values. In order to get up to date values I have to exit Notes, start it again, and then the lookup gets the accurate values.
I can’t understand what the problem is: In the same form I have a similar field with a similar lookup and that works fine. They even get the values from views that show data created with the same form and the views are identical except for the field, from which they get values. I have tried everything I could think of, with no results. In the web this lookup works ok, so the problem lies somewhere in the Notes Cache, but does anyone know where?
Has anyone else experienced this kind of problems? In this forum there are a couple of postings about these kind of problems, but so far no-one has been able to get any answers. Is there actually a major bug in the system?
I was never able to resolve it to my satisfaction and as a workaround had to use a LotusScript that called view.Refresh.
I’ve read Andre’s response to your post. None of his suggestions applied or helped to resolve my situation - it was a straightforward @DbLookup in a DialogList field type; the “Refresh Index” view property was set to “Auto, after first use”; and the “Discard Index” property was set to “Never”.
Since it was a single line of code I never tried an @Prompt to establish order of execution/calculation although I did put the @DbLookup inside @Prompt([OKCANCELLIST];…) in a button - and still retrieved the cached data. I also had the “Refresh fields on keyword change” and the “Refresh choices on document refresh” field properties checked.
I never encountered the issue again and can’t explain it. In other words I was never able to recreate the issue outside of the database I was working on at the time - I’ve got a copy of it which still doesn’t work (the @DbLookup, that is). It’s basic bread and butter stuff I expected to work like it has done for me for a dozen years or so. I thought it was a bug at the time but since I was unable to recreate it elsewhere I’m now not so sure about that.
I’m afraid this posting probably won’t help you much but at least you’ll know you aren’t alone.
Hope you get it resolved or that others post details of their own encounters with this.
Subject: RE: Mysterious Cache: DBlookup gets data from cache in spite of NoCache
If you have a database that still exhibits this problem, then please email it to me. andre underscore guirard at us.ibm.com. Is the lookup internal to the same database, so that the one database is all you need?
Subject: RE: Mysterious Cache: DBlookup gets data from cache in spite of NoCache
Delighted to. May take a week or two though since I’m currently seperated from by bits and pieces and I’ll need to have a hunt when I get near them.
Meanwhile, yes. The lookup is internal to the database; nothing extra is needed. I maybe should have added that the database was local and that the issue was neither ‘tested’ nor investigated on a server replica.
I’ve a niggling thought it may have been something to do with the UserID.
Thanks for taking the interest. I don’t want you to be wasting your time but I hope it turns out to be nothing. If it is I’ll be sure to modify my earlier posts on the matter.
Subject: RE: Mysterious Cache: DBlookup gets data from cache in spite of NoCache
Before I address your question, I have to say this because it’s really bugging me.
Didn’t anyone show you how to use temporary variables in formulas, or @IfError? It’s incredibly wasteful to do two identical @DbLookups in the same formula, particularly with NoCache.
Now, to answer the question you asked. There is not a known issue with NoCache failing to ignore the cache. There are more likely problems that, in my opinion, you have failed to eliminate as possibilities.
This formula is not being calculated when you think it’s being calculated. Add an @Prompt at the beginning of the formula so that you can be certain when it’s being executed.
The view index is not up to date. Data displayed in a view does not always reflect the data stored in the documents. Views have indexing options that control how frequently the index is updated. In addition, if the view selection formula or a column formula uses @Now or @Today, that may affect when the index is updated.
You didn’t mention exactly when and how the documents you’re looking up from were being modified. It’s possible you are having some confusion about what order @functions and @Commands are being executed – or what order @Commands and other @Commands – or when the changes you make with @SetDocField are actually being saved.
Thanks a lot! I had already checked everything else you suggested but the view selection formula did use @Today and I didn’t see any other way to do it and I did not realise it had that kind of an affect on the indexing. I now managed to make the selection without using @Today and now the lookup works ok.
The posting that Ian F Scott referred to was actually one reason why I suspected that there is some bug in the DBlookup. I was waiting for someone to reply to that one, because the problem seemed very similar to what I was dealing with. I think Andre’s list will be helpful to all of us struggling with DBlookups. And thanks for the tips on temporary variables too
