First of all, a little perspective. As the code in question was to be run as a Lotus Enterprise Integrator (LEI) scripted activity, we could not use the agent's "run on" property of "New of Modified". That's because the LEI Scripted Activity agents live in the LEI Vault database, but actually run on data kept in other databases. The Last Modified property only applies to the database the agent lives in.

So we created a view in the target database, and used the view column value simple selection of Last Modified, as shown in Figure A.

FIGURE A

We selected Last Modified. Click picture for a larger image.

OK so far. Until we looked at the view. What we found was that the value in the view wasn't the actual document Last Modified value for the documents, as they were in this database.

Let's have another aside. Look at a document properties box, and at the first tab, in Figure B.

FIGURE B

There's some interesting evidence in this one box, as long as you know where to look. Click picture for a larger image.

Notice that there are four dates in it. The first one is the date that the document was initially created in the database it was initially created in. Next comes the date of Last Modified in that same database. Now the next two relate to the actual database that you are looking at -- which, with Notes' fabled replication, doesn't have to be the same instance of the database. And in our case, it wasn't -- the database we were working with is was a distant replica, maybe two servers removed from the one that the end users actually use. And this is where the whole problem started.

We found that the view's simple function Last Modified value came from the Modified entry, at 11:04 in Figure B. This isn't the last modified time in the current database, and to be honest, if it's not in the current database, it can't be relied upon. Even if you think that you have properly synchronised clocks, I'm not sure that you can rely upon them to always be synchronised, and anyway, in our environment, we knew we couldn't rely on this entry.

This was a bit of a bummer for us, because we planned the agent, when it ran, would record the time and date it last ran. Then next time it ran it would look for documents modified after that time, then record that last run time, and so on. We could not stamp the documents that we were processing with a processed flag, because while we were working on them, there was always the possibility that end users could also be working in them -- so when the next replication happened, we'd get lots of rep/save conflicts. A definite no-no.