indexer and the SQL table

Hi to all,

recently noticed the following behavior with the indexer and it's relationship with the SQL tables, so if bear with me...

was upgrading our internal iManage NT server from 7.5 to 8.0 and after installing the indexer (v5) and decided to re-built the index what happen was I let the index manager run throughout the nite, and next morning noticed from the log that after indexing for 2 hours, errors occurs and I had many 'F' and 'B' status in the DOC_INDEX entries. So did some investigation & realised that the temp directory was short of diskspace. clear it up and after 'playing' with the DOC_INDEX entries found the following behavior:

a. If I was to edit the SQL table entries to turn a record from 'F' or 'B' to 'N' and let the index manager run, (as continous), the re-indexing works.
b. strangely, the LAST_INDEX_TIME did not reflect the time the status was last updated after the index agent succesfully re-index that particular document. My guess is that it reflects a earlier time & I suspect is the first index time for that document.
c. In earlier tech notes, I am supposed to update the DOCMASTER to update the INDEX value from 'Y' to 'N' to start the re-indexing but this is not the case for the docnum in question.

now I'm confused, can someone tell me if the INDEX column in DOCMASTER is relevant anymore? and is the LAST_INDEX_TIME column a misnomer? Better still, can someone really run through the indexer steps in greater detail than what is documented in the server guide?

thanks in advance

Edited by bpsong on 05/06/04 11:36 PM (server time).

Find more posts tagged with

Comments

jny

This should be addressed in greater depth by Technical Support Staff. My advice is to open up a call with them.

This does not appear to be an issue involving custom development using the COM APIl's distributed with the SDK thus it might not be appropriately and adequately addressed in this forum.

Migrateduser

The last index time is stamped at the time the content is chosen as a candidate for indexing and placed into an assigned index collection (physical collection file), i.e. when a row is inserted into the DOC_INDEX table, not when it is actually indexed. This is because there is an indeterminate quantum of time between when it is selected as a candidate and when it is actually indexed. The document could be modified within that window and that edit could be lost from the index.

The INDEX column in the DOCMASTER table is not used to determine content indexing candidacy in modern versions of WorkSite. I would recommend using the reindex utility, not direct manipulation of the SQL table, to flag content for another indexing attempt.

bpsong

thanks, will keep it in mind your advise.