Developing a Robust "Search"

     That "Search" button at the top of this (and every other) page turned out to be a real pain to implement.  It was compounded by an incomplete solution from Microsoft's FrontPage 98, the sparse and exceptionally technical documentation for Microsoft's Index Information Server v1.1, the confusion of that product with the Microsoft Internet Information Server (also "IIS"), and the poor integration of all these products with one another.

Creating Search-ability for the User

     When using FrontPage 98 (FP98) to build a new web site you're presented with the option of having a Search page.  The goal is to provide visitors to the site with the ability to search the site for key words or phrases...a devoutly to be desired capability every active site needs.

     FP98 produces  properly formatted "search.htm" page.  When the website is "published" to the server (an act, essentially, of copying the web site with all its pages, changing all the internal hypertext links to properly reflect the server's name), the search page goes along...with not a single hint that it won't work!

Supporting Searchability at the Server

     A quick search on The Web turned up a cryptic note at PMP Computer Solutions' site that held the clue (thanks Roberto!).  Of course, the note warned "...requires some knowledge Index Server.", so that set me off on my next search.

     I found The Index Information Server at Microsoft's web site by searching on "index server" (hmm-m-m.  using MS' Index Server to find the Index Server software; wouldn't Hofstadter, Gödel, Escher and Bach have something to say about that?).   Downloaded it, and installed it on my web server computer.

     But, my hopes were dashed for an easy cure when, in trying out the Search button (above, remember?), it go the following lucid and informative message on a page all by itself (best read aloud by using your best dramatic announcer's voice):

The catalog directory can not be found in the location specified by 'CiCatalog=' in file d:\WWWRoot\_vti_bin\search.htm0.idq.

Isn't that just about as clear as mud?

     The documentation isn't much better:  The only way I could find it was to search the entire hard disk on my server for "CiCatalog".   That turned up several pages which, with a bit more magic to configure the server magically became accessible to by Internet Explorer browser.  I found that file named in the dreaded message, and found out what "CiCatalog" means, and took the following steps:

1. Created a directory named "Catalog.wci" on the hard disk, as described in the Index Server's CATHLP.HTM documentation.  You might already have one, if your webmaster ever tried to perform a search on this server to test the setup.   We elected to put it under a directory named WWWIndex on the D: drive of our server.
These next steps were taken in a special file created by FrontPage 98:
      " d:\WWWRoot\_vti_bin\search.htm0.idq ".
If you want to see that file, click here.   We annotated it for your benefit.
2. Added a line reading "CiCatalog=D:\WWWIndex" (that is, the directory in which the "Catalog.wci" directory will be found) to the file
3. Added a restriction on searching (... & ! #vpath *scripts/* ) that prohibits the script itself (and anything else in that directory) from being included in the search. 

     Voila!  It works...after a fashion.  I can search for words, and I get a rather crude-looking list of results back.  But...

Needs Further Work

     Well, this exercise only consumed about ten hours of reading through a welter of confusing details about how to change registry settings, and all sorts of other things.  So, at this point, something works, but I'm not yet convinced that it fully works, that everything that should be found can be found, and that nothing that shouldn't be found is returned to the user.

     And, the user interface is crude, at best.  So, we have to revisit that issue, too.