Hi Larry,

Not a new contractor yet but....

He suggested that we incorporate an "Index Document" into each binder when the binder is created and it contains the necessary key words. He then rewrote this section to search using the index documents and it is indeed much faster. Here is his code (C++ code that we are putting into a dll called from VFP).

It appears from my read of the code that he is searching for documents that match the search criteria (strSearch contains a search phrase that matches what we need - we search file File_Number (an internal number assigned by VFP) and the Plaintiff's Last name and it appears the search is limited to uust index documents). Not sure if his search is accurate but it seems to work. When viewing these index documents, the document shows a simple string that he has delimited with a percent sign eg. a doc that contains just the lastname and file number looks like this for Joe Blow, file number 12345

12345%Blow

Don't know if this is the best way to search but that's what he is doing. Any comments would be appreciated. Note that strFileNo and strLastName are passed into the dll. I do not understand why he is explicitly naming fields here when it seems that he is searching something that I would call "a memo field". But maybe the index is getting the number of matches down to a few records and then Notes is further restricting based upon actual fields (much like Rushmore).

CString strSearch = "([File_Number]CONTAINS\"";
strSearch += strFileNo;
strSearch += "\")and([Plaintiff_Last_Name]CONTAINS\"";
strSearch += strLastName;
strSearch += "\")and([Is_Index_Document]CONTAINS\"Yes\")";

try
{theDocuments.AttachDispatch(theCabinet.SearchDocuments(strSearch, 1, 0, 0));
}
catch(CException* e) {
e->Delete();
tcBinderID[0] = '\0';
cbBinderID = 0l;
return ERROR_SEARCH;
}
if (theDocuments == NULL) {
tcBinderID[0] = '\0';
cbBinderID = 0l;
return ERROR_SEARCH;
}

try
{theDocument.AttachDispatch(theDocuments.GetItemByIndex(0), TRUE);
}
catch(CException* e) {
e->Delete();
tcBinderID[0] = '\0';
cbBinderID = 0l;
return ERROR_SEARCH_EMPTY;
}
if (theDocument == NULL) {
tcBinderID[0] = '\0';
cbBinderID = 0l;
return ERROR_SEARCH_EMPTY;
}

try {
theBinder.AttachDispatch(theDocument.GetBinder(),TRUE);
}
catch(CException* e) {
e->Delete();
tcBinderID[0] = '\0';
cbBinderID = 0l;
return ERROR_SEARCH_BINDER_NOT_FOUND;
}
if (theBinder == NULL) {
tcBinderID[0] = '\0';
cbBinderID = 0l;
return ERROR_SEARCH_BINDER_NOT_FOUND;
}

>It sounds like you need a new contractor. <s>
>
>While the Search method may not be optimizable in the Rushmore sense, it will definitely be faster than querying each binder for its name properties. You can also the GetDocumentByKey method of a view. Find (or create) a view that has a list of the binders. You can do a search based on the columns marked as Sorted.
>
>See http://www-12.lotus.com/ldd/doc/domino_notes/5.0.3/help5_designer.nsf/f4b82fbb75e942a6852566ac0037f284/75b48a3b93ae813e8525687e00598639?OpenDocument&AutoFramed.
>
>Because views build indexes, this will be optimized.
>
>HTH.
>
>>Hi Larry,
>>
>>I am going to try your code for instantiating a Notes object but one question from the below - in talking to our Notes developer (contractor), he does not think that the query would be optimized in any way because he said that "indexes cannot be attached to a field like in VFP". I had assumed that if it was an ODBC driver that the driver would use whatever indexes it could find. What do you think - optimized or not?
>>
>>Albert,
>>
>>1) The Notes ODBC driver does support the basic SQL query syntax. Using SPT or remote views, you can query on a view and the result set will be returned as a VFP cursor. You can also use the object model and return a document collection and parse through that. The query would be optimized within Notes so the major processing would be done going through the collection.