Thanks.. will do.

[quoted text, click to view]

[quoted text, click to view]

I also know it "not ready for prime time"; how many document systems
have you implemented? I have one under my belt for the Labor
Relations legal section of a major untility company, consulting for a
company with an FBI contract (not sure if I want to admit that), and
a few much smaller ones.

And it is not well integrated; it is paste-on to an existing storage
model that does not work well with text. Just as a record is not a
row, a row is not a document. There are no semantic net indexes, no
fuzzy operators. The full text columns have to be kept in a form that
can be read by SQL, instead of a compressed form designed for text
searches.

What they have is an early textbase with a Thesaurus (not maintained
by engine, but by the user), "Noise Word" list kept outside of SQL,
and only simple pattern matching, proximity (not adjustable) and
grammatical forms. An occurence computed on word position within a
row ("foobar is word #42 in row #12") and there are much faster ways
to locate things. Oh, and no quorum operators either.

And it also does not follow either SQL conventions or ANSI/ISO Z39
Standards. In fact, the syntax is really weird and hard for non-
programmers to learn. The real coument users know Lexis, Nexis, West
Law and other similar languages.

If it is all you have and you are not doing serious document searching
and you are a programmer and not an end user, then you can probably
get by. For fun, look up ZyIndex which was the "Gold Standard" for
textbases and see the differences. And there are products that beat
it now.