×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 23-Jul-2010 06:57, Charles Wilt wrote:
v5r4...actually yes DSPSFWRSC does show the text extenders
product installed....
However, I have a suspicion that we don't actually have a license
key for it. Unfortunately, I don't have authority to WRKLICINF
to check, and there doesn't seem to be a DSPLICINF
command....though I thought there was another way to list license
info...
Using the Text extenders would be ideal, but I'm afraid of issues
of compatibility between them and our CMS along with our current
security settings.
Still, it's worth looking into, I didn't realize they were even
installed.
I am not sure of the implementation of the TextExtenders, but a
private implementation need not ALTER the existing TABLE; as was
alluded in earlier discussion, is done by the TE feature.
Depending both on the limitations that could be imposed on the
user search requests across that 25-byte character field and the
existence of a hopefully unique key to identify a matching row,
implementing the effects of a token-ized search is not much more
difficult than completing the code which produces the tokens. If
the searches can not be limited to actual tokens, those searches
which still require full scans, but those can be limited to the
token-list table rather than the master table.
Given the string '123 N.MAIN ST.' parsed into the tokens '123',
'MAIN', and 'ST', and having each of these inserted as a keyed
column with matching column and data for the keys of the original
file provides a matching join and thus keyed search for any LEFT
portion of the tokens.
A big concern is for how much in sync the keyed token-list must
be with the rows in the master file. A trigger, deferred I\O
trigger, or parsing the logs\receivers are all options. Another
concern is omitting "bad" searches; e.g. notice that "N" was not
stored, because searching on a single byte is not a "good" search.
With specific logic to introduce apparent consistency\smarts,
even with the possibility of introducing /false positives/,
assumptions about the data can be made and the storage of /presumed/
tokens versus actual tokens can be effected. For example the "N"
could be presumed to represent "NORTH" and be stored as such, just
as "ST" for "STREET". On the search interface, the same data
transformation would have to occur to /correct/ the search token
specified by the user; the search interface might choose to balk at
a search on "N" versus changing the query to effect implicitly the
search on "NORTH".
Regards, Chuck
midrange.com
