Probably an access problem.

Check if the agent signer is supposed to access the database or if the windows account used for the domino server has enough rights.

Thanks for your reply Emilie

Unfortunately it is not a rights problem. The agent clearly has acces to the DB (can read ACL, Data docs etc.) and I meanwhile have written a quite slow but working workaround:

Have replace the n&= DB.AllDocuments.Count by a method, that first tries to use the normal AllDocuments method and if this one fails (error 4005) it creates a NotesNoteCollection for all DataDocuments and so gets the number of documents. But (!!!) this is very slow, it takes around 100-160 sec alone for this one DB ! The agent usually needs 20 seconds for all 400+ db's ... ;-)

 But this is a  workaround and  not really a solution for this error. The question is what is going on in this DB. Is there more coming ?

Will today create a copy and then try to compact the whole DB.

Will keep you informed.

Joe

Hi all,

First of all , Steve, thanks for your reply, I think your explanation is pretty close to what actually happend.

Meanwhile we have compacted the database and it's size went down from 13 GB to only 4GB ! And, most important, afterwards I could and still can get the total amount of docs in the database via db.GetAlldocument.count.

This made me a bit curious about what could have been the reason for such a big difference in size  as there were no data losses at all. I found out, that this DB is used as a backup DB for a ticket DB. Every day new tickets get stored in it and ... everyday those older than 1 year -  get deleted. So obviously this DB must have been used for a while without compacting and I assume that all those deletion stubs must have added up to a huge amount and have caused this condition (my theory). But its strange that the cluster servers do not report a db with such extreme conditions. 

I really would appreciate if IBM could give us their official error explanation(s) ...

Joe

Hi Steve,

thanks so much for your reply.

Yes, 9.01 indeed. I will inform our administrators about that compact column you described.

Appart from this will my agent in the future be able to handle such a condition and  will add a warning line in the admin email and  all logs concerned.

Joe Herrmann

Just for future reference, I've run into a number of databases that claim 95% & up usage. Then on compact, the size of the DB drops like a rock (well over 50% recovered).

I'm not sure of the cause but this sounds possible. I've taken to requesting compact for databases that seem large for their doc counts.