Building a search engine into a project

[Wilhelm Sanke]

On Sun, 04 May 2003  James Lewes <jameslewes at comcast.net> wrote:


> I was thinking of using Revolution to build a catalog for a bookstore.
>
> Does anyone have any suggestions on how to make it expandable and searchable
> without having to link it up to a database.
>
There were already some responses to this question, among them the
suggestion to try out the find command.

For my own purposes I tried a search routine based on the lineoffset
function.

While fighting with the sometimes very slow speed of the old Rev
Application Overview, especially when dealing with larger number of
cards and/or controls in a stack (we had a discussion about that a long
time ago on this list), I put together a RevBrowser (and a MCBrowser for
Metacard) for better performance that included a search routine to
search all control scripts of a stack - as one of several options.

James Lewis´s question let me take a second look at that old search
routine. I substituted text fields for controls and got a search routine
of which I am unsure if the speed would be compatible (or tolerable) in
comparison with "real" databases. I`ll provide more information about
that aspect in a second.

The features of that search routine are:

During the search the following information is shown:

- the number of cards still to be searched
- the number of fields in which the searchstring was found
- the cumulative number of hits in these fields

When the search is completed the displayed results comprise:

- the address of the hit: name of field, ID of field, name of card, ID
of card
- the text of the lines of the field with the found searchstring along
with the line number
- the searchstring in each found line is displayed in red

When you click at the line of the address, the respective card of the
searched stack is immediately shown (i.e. this works apparently faster
than the routine of typing a search word into the "find" field of the
transcript dictionary).

The question of speed for a search routine may indeed be a decisive
issue. I used an older version of the Transcript Dictionary as a test
stack.

On a comparatively slow Windows computer with 800 MH to search the 13812
fields of the 1152 cards took 22 seconds to display the result as
described.

The speed could probably still be optimized if you leave out some of the
information that is being searched for in the  current version of the
search routine -

I do not know whether this would be interesting to James Lewis or
others.

Let me know offlist when you should be interested in that search
routine. I have yet to "polish" that stack to make it presentable; if
there are more than a two or three requests, I will place that stack on
our FTP-server.

Regards,

Wilhelm Sanke