Hi,
I have a LS that performed a db.search.
Server : 6.5.4
client 1 : 6.5
client 2 : 5.0.10
Test: I change the value of a field in one document
Result :
When my script runs on the R5 client , the results are good.
But on the R6 client, the results give me the old value of the document.
Can anyone help me ?
Tx in advance
Cathy
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
Sounds like the full-text index is out of date. It might be permanently out of date because it’s from an earlier version of the database incompatible with the current full-text indexing format.Try deleting and recreating the index.
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
Tx for your response and sorry for my late response.But db.search is not linked with the FT index (like FTSearch).
The problem appears again. I have to close the database and reopen it to “refresh” the documents.
tx for any help.
Cathy
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
Sorry, read too fast. The problem is probably due to your using a NotesDocument object and then not using Delete to remove it from memory cache when you’re done with it. Next time you use the same document in the back end, it gives you the old cached value.
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
tx Andre for your response.How could I delete the cache to have the updated document ?
Do you mean that i have to put this line at the end of my code :
Set coll = Nothing
?
Tx cathy
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
I try set coll = Nothing
and there is no change
The only way to have the good results is to close my lotus Client and reopen it !!!
And it seems that one of my users in R5 (i don’t know yet the exact release) has the same issue.
Cathy
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
No, when I said you have to use Delete, I actually meant you have to use Delete, as in:
Set docCur = coll.GetFirstDocument
Do Until docCur Is Nothing
Set docNext = coll.GetNextDocument(docCur)
' INSERT CODE HERE TO PROCESS A SINGLE DOCUMENT
Delete docCur ' so documents don't accumulate in cache
Set docCur = docNext
Loop
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
What I don’t understand (and maybe I’m being stupid here) is why deleting docCur helps with the cache and memory in the loop… but don’t you keep caching the documents on docNext each time you replace it with a new value? Why aren’t you trading the caching of one doc object for another?
If you could test for docNext being nothing and delete it at the very end of each loop cycle, perhaps… but this will slow things down and take away from any advantage to the garbage collection, no?
-T
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
tx for the clue.
To have a good results, I have to write the code like this (it’s strange). I have to loop the collection twice :
Set coll = db.search (formula$, Nothing, 0)
Set doc = coll.getFirstDocument()
While Not (doc Is Nothing)
Set docNext = coll.GetNextDocument(doc)
Delete doc ' so documents don't accumulate in cache
Set doc = docNext
Wend
Delete coll
Set coll = Nothing
Set coll = db.search (formula$, sDate, 0)
… next of my code
Tx for your help
cathy
Subject: RE: db.search works fine on Client R5 but not on R6 (it retrieves old values)
This is because those documents are being left in the cache by some other script that’s failing to clean up after itself. Or maybe, depending what you edited and ran when, they were left over from the last time this script ran. In any case, if you can’t find the script that’s causing the problem and you want to fix this one without having to do two searches (very wasteful), you could store the note ID of a document in a string variable, “delete” the document, then use GetDocumentByID to fetch it again – then when you’re done with it, “delete” that also, of course.