Sharing indexes on a network, and indexing across a network connection.
The rules for concurrent access with dtSearch indexes are: users can share access to an index while searching, even if an index is being updated, merged, or compressed, but only one user at a time can have write access to an index. Therefore, when an index is being updated or compressed, no other users can modify that index. (A "user" is a single process or thread. In a multi-threaded application, only one thread at a time can have write access to an index.)
A user who starts a search while an index is being updated will see the index as it existed before the update started. Once an index update commits, searches that begin after the commit will see changes made to the index by that update.
If an update is terminated abnormally, the index reverts to its state as of the last successful commit. Searches will remain unaffected by the failed update. At the start of the next index update, any invalid data added by the failed update will be removed before new data is added.
dtSearch can create an index in any writeable folder, local or network, whether expressed as a mapped drive or a UNC drive. However, there are two advantages to running dtSearch on the same physical machine where the index is stored: (1) index updates are much faster, because index access does not occur across a network connection, and (2) potential index corruption caused by network write errors is prevented. Indexing involves a great deal of read/write activity in the index folder, and it is much more efficient if this can be done locally rather than across a network connection.
Searching involves much less disk access than indexing, so there is no need to run dtSearch on the same machine as the indexes when executing searches.