We have an application were data is updated via odbc from an access database. There are existing documents updated and new documents build this is done by lotus script code.Afterwards runs an agent which updates one field on these documents using formula language. This second agent has the target of all documents in the database but it is not working correctly as it works only on part of the documents. We found out that this behavior has to do with the full text indexed not being updated fast enough. But why is the full text index intervening if I tell the agent to run on all documents. I could not find any information on this subject in the official help files.
Will it help if I change this second agent to lotus script code ?
Subject: RE: agent document selection problem with ft index
I wouldn’t expect the language of the second agent to matter.
If you run on all documents, I wouldn’t think the FT index would make a difference since it is only used when there is a search. What makes you think the FT index is involved with this problem?
But you actually are not running on all documents, but on new and modified documents, right? So the key point is whether the document appears to be “unread” to the agent.
But I wonder, you’re updating a lot of documents; if you have an agent that runs on new and modified documents, and there are multiple agent threads, it has no way to know that you’re (let’s say) 40% done with your run of the first agent. It’ll run on whatever you’ve modified to that point. Then it should run again later on more documents that you’ve modified since the first batch.
Why would you not do your one-item modification in the agent that does the ODBC operations?
Subject: RE: agent document selection problem with ft index
First of all thanks for your answer !
There is a search because the document selection is restricted by a formula within the agent depending on form used.
I thin the index is involved because I know that with the first agent we acted on 635 documents and all of them meet the criteria. Afterwards we started the agent manually and it ran only on 404 documents. Then we found out that the amount of non-indexed documents was 635 so we came to the conclusion that it has to do with the index.
Actually both agents run on all documents in the database. The restrictions for the first agent are built in the lotus script code.
The agents were developed by a colleague who left the company but I believe he divided it in two agents because the first agent is working on odbc and the second updates within the Notes database.
Subject: RE: agent document selection problem with ft index
Restriction using a SELECT statement does not involve the full-text index. The recently modified documents are not indexed right away because there has as yet been no call for them to be indexed; the second agent doesn’t try a full-text search, so the indexing can wait until the next scheduled time.
If an agent’s set to run on “all documents,” and the agent has no “document selection” query, the agent will run on all the documents that meet the selection criteria in the SELECT statement (unless you have e.g. a @Return before the SELECT statement). Unless there are documents that the ID running the agent has no access to view, because of Readers fields. Perhaps there’s a logic error in your select statement. Perhaps the first agent is not saving all the field values you think it’s saving. All I know is, based on what you have told me, the full-text index does not come into play. That’s a dead end.
There seems no good reason to split this into two agents, if you never want to do one without doing the other. If the ODBC code is updating Notes documents, it can just as well update one additional field.