Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

Charles Robinson writes:

I remember reading on Notes.Net that using db.Search({criteria}, Nothing, 0) was much less efficient than using db.Search({criteria},SomeDate,0).  Specifying something for the date -- even one far into the future -- reduced search times by some incredible amount.

Interesting; I hadn't heard that one. Do we have any volunteers to test it?

I asked this on the original thread, and I'm bringing it up again because no one responded.  In my experience the UnprocessedDocuments flag for an agent gets reset when the agent is saved.  For example, run an agent that acts on UnprocessedDocuments, edit it and re-save.  It will process the same documents again.  Was I doing something wrong, has it changed in more recent versions, or is that working as designed?

Assuming you're talking about a "New and modified documents" target, that's what's supposed to happen.

Finally, in most cases that I would use a document selection formula in an agent I need something like "[Job] Does Not Contain "" ".  How do you specify you only want to include documents that have any value in a field?  I usually end up with an agent that runs on all documents and something like this:
SELECT Form = "Pirate" & Job != ""
Inefficient, I know, but it's the only way I know of to get the documents I need.

Use "is present," e.g. ([form] = "Pirate") and ([job] is present)

It's not documented, and I found out about it relatively recently myself. I made them add it to the online help for version 8.0, in the document titled "Refining a search query using operators."

Andre Guirard | 13 April 2007 11:12:21 AM ET | Nicolin B&B, Jordan, MN, USA | Comments (7)


1) thanks for the response
Charles Robinson | 4/13/2007 2:05:34 PM

1) I did some rudimentary testing and using a cutoff date was actually slower than using Nothing, but it's splitting hairs: .222 seconds versus .297 seconds. The database I'm using is 46MB, has an FTI built, and I'm returning 25,422 documents. I've been digging through the forums and can't find the original discussion now.

2) Under what circumstances would editing and saving the agent NOT reset whatever tells the agent it's already processed a document?

3) That's really good to know. Thanks for sharing. :)

2) Seaches
Mike Amberg | 4/13/2007 4:26:01 PM

I found the following related information

{ Link }

I also remember reading an article that had the results of different searches methods with timings posted.

Now if only i could just remebber where ...

3) re: thanks for the response
Andre Guirard | 4/13/2007 4:35:49 PM

[i]> Under what circumstances would editing and saving the agent NOT reset whatever tells the agent it's already processed a document?[/i]

If the agent doesn't run on "new and modified," then this information is not tracked, so there is nothing to reset.

Otherwise, you'd have to have the agent track documents it's run on by some other mechanism, e.g. have it set a field in the document to flag it as processed. Maybe you could have it check its own HasRunSinceModified property, and if this is its first run after modification, have it determine its last modified date/time (probably would require use of NotesNoteCollection to find the agent design note?) and run through the UnprocessedDocuments collection, marking as processed and removing from the collection anything that was modified before that? Of course, if there were documents awaiting processing when the agent was edited, they could be skipped.

Anyone else have any ideas?

4) Present
Theo Heselmans | 4/17/2007 5:38:39 AM

Wow, 'is present' is a great present !

The number of times I needed to search for an empty field !

You made my day, no make that month !!

5) Splitting hairs?
Jordan Tenjeras | 5/21/2007 9:20:23 AM


Does 'is present' test for the existence of the field or does it test for the field being blank? As I read Charles' comment and code, I don't see how the logic can be improved upon. Is 'is present' better performing?

It seems like 'is present' is equivalent to @IsAvailable which is different than testing for the value of a field.

6) About ’is present’
Edwin Liu | 9/27/2007 4:17:43 AM

Hi Andre

The 'Query is not understandable' error generated when I used 'is present' in the document selection formula. I am using Notes R6.5.6. Is this a new function for R8?

7) Proper UI search syntax, not in agent...?
Lisa Rahder | 1/2/2008 11:01:30 AM

I am trying to search for all docs with blank custom date field, and tried your agent syntax in the UI FT Search box... no luck! It seems to operate in the manner that Jordan Tenjeras describes in "Splitting Hairs" above... Do you know the proper syntax in the UI Search to search for a blanck custom date field?

8) re: Proper UI search syntax, not in agent...?
Andre Guirard | 1/7/2008 10:20:16 AM

I've been experimenting with IS PRESENT, and it appears to work only for text items. But for those, it treats documents that do not contain an item the same as documents that contain an item but the value is blank. That's the way we would usually want it to work.

To find all documents where a date field is either blank or not present, you can pick a date that you know all the dates in your application will be later than, and use a query such as:

NOT ([DueDate] > 1/1/1920)

If there's no such date, you could still do it as follows:

NOT (([DueDate] > 1/1/1920) or ([DueDate] < 1/2/1920))

If you wanted to distinguish between blank and unavailable, you would either have to use a different type of search, or filter the results yourself with a loop and discard the ones you don't want.

9) @IsAvailible Gotcha
Kerr | 1/7/2008 12:26:49 PM

Since I got bit by this the other day and this thread mentioned it in passing, I've found an interesting little @IsAvailible gotcha.

In 6.5 (not sure about other versions atm), if you have a column with a simple field value in it, the programmatic use field for it defaults to the same name. Having that column there makes @IsAvailible evaluate true for all docs in the selection formula and any column formula following the column with that programmatic name. If you change the programmatic name you get the results you probably want.

Once I figured out what was happening I could see the (slightly twisted) logic in it, but it's not very intuitive, especially the evaluation of the select formula.

Man, I should get a blog for this kind of stuff :)

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact