Since our migration from 5.0.11 to 6.5.1 we experience problems with view indizes on various dbs. The views always show one or two documents that have actually been deleted from the db but still show them in the view. When the user tries to open such a deleted document we get “document has been deleted”. Well, we deleted and rebuild all views in those dbs using “compact -D” and “updall -C” which solved the problem for a while
Today, about 15 days after we fixed the problem on that particular db, the same problem occurs again.
As said, the problem occurs also on other dbs. We initially put this down to a migration issue, so we assumed that once all DBs had their view indizes trashed and rebuild we should be fine, but todays re-occurance of the problem is worrying…
I’ve been searching the forum and the knowledge base and can confirm the following:
None of these dbs allow soft deletions
None of these dbs have a FT index
The db with the re-occurance has no reponse documents
There’s nothing much suspicios in the view design.
Our servers are running 6.5.1 on W2K3, mainly web applications, designers are still using 5.07a.
Subject: Reappearing ‘document has been deleted’ even after compact -D
Hi
When a document is deleted, it leaves behind a deletion stub. When the database replicates, Notes uses the deletion stub to identify and delete the same document in the replica.
To save disk space, Notes purges deletion stubs that remain from document deletions according to the replication setting “Remove documents not modified in the last days.” If Notes purges the deletion stubs before they have a chance to replicate, deleted documents can reappear after the next replication. This option is on the Space Saver panel of the File - Replication - Settings dialog box in the Notes client.
If you check the Admin help for “deletion stubs” or “purge interval”, you may be able find some more info to help you out.
Subject: RE: Reappearing ‘document has been deleted’ even after compact -D
Thanks Andrew
Our problem is seems more related to the view index than to deletion stubs. It’s not that documents are actually re-appearing in the database because the deletion stub got purged and hence the documents replicated in from another replica. Our problem is that a document that has been deleted from a database still appears in a view, so the view-index is not being updated correctly.
We can fix the problem with a compact -D, but the problem reoccured in that same db after 4 weeks (something like 30 days - which could point to deletions stubs again, but I believe that’s a coincidence).
Subject: RE: Reappearing ‘document has been deleted’ even after compact -D
Hi again
To ensure i understand, usually in the view, you delete a document and it disappears. But after some time (4weeks), if you delete a document it doesn’t disappear? In that case, indexes do sound like the problem. Sorry for misunderstanding your first post.
What happens if you refresh the view after deleted document doesn’t disappear? i.e. hit
What happens if you rebuild the view index after deleted document doesn’t disappear? i.e. +
In the design of the view, what is the refresh and discard settings for Index? Could one of these be causing a problem?
If the discard index interval is set, is the ‘updall’ tasks running on the server correctly? What settings are there for the ‘Updall’ task? Perhaps set "updall -V " to run every night?
Sorry i said nothing definitive about your problem, i’ve not seen it before. But am just thinking what i would try to solve it.
Subject: RE: Reappearing ‘document has been deleted’ even after compact -D
Hello Andy, thanks for your reply.
Recap of the problem:
The document gets deleted by a web user or an agent. We I did that the view properly refreshes and does not show the deleted document anymore. Everything’s fine.
After something like 15 days, we open the view again and try to open some documents that are listed in the view → ‘document has been deleted’, regardless whether we use Notes or web-client (it’s a web application).
No luck with F9 or Shift-F9.
The view-index settings are (which I believe are the defaults):
Refresh: Auto, after first use
Discard: If inactive for 45 days
We run Updall once at 4am on all DBs without params. Seems to be running ok, no errors in the log. We do have some UPDALL -c progdocs on the addressbooks, but that should not relate to application indizes…
The only way we can fix the view index is by deleting the view indizes using a COMPACT -D. Although this is a workaround, we cannot do this regularly on all our applications.
Subject: RE: Reappearing ‘document has been deleted’ even after compact -D
Well, Lotus Support came now suggesting running an UPDALL -r on all DBs once a week, which indeed corrects the view corruption, but I’m not all that happy with it for now…
Subject: RE: Reappearing ‘document has been deleted’ even after compact -D
Hi again
I suppose weekly updall -r would ‘solve’ the problem , or is that ‘suppress the symptoms’ of the problem. It would be nice to know ‘why’ it is happening.
Nearly out of ideas, but gave it some thought over the weekend. Have you tried the view index refresh at “automatic”?
You say the documents are deleted via the web or an agent. Is the code you are using to delete the documents same for all databases that have this problem? Would a view refresh after document deletion have any effect on the view indices? I suspect not, but maybe worth a try.
out of ideas now, so good luck, both with the problem and Lotus support
Subject: RE: Reappearing ‘document has been deleted’ even after compact -D
Well, to close this off and if anyone’s still following - we did not have any new occurances if this problem after we’ve deleted and rebuilt all views on all DBs in our environment. So far I was also not able to force the problem to occure with a replicating test-DB which creates, deletes a couple hundred documents each day.
Really seems to be a one-off thing, maybe R5->R6 migration related…
