HP3000-L Archives

December 1998, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Tue, 29 Dec 1998 10:21:09 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
Wirt writes:
> Shawn asks:
>
> > Strangely query does not seem to properly handle a zoned field as a key
> >  when doing wild card retrievals in query.  Consider the following;
> >
> >        ITEMS:
> >           CLIENT-EMP-NUM,       Z12           <<SEARCH,INDEX ITEM>>
> >  >F CLIENT-EMP-NUM >= 000220000000 AND CLIENT-EMP-NUM < 000230000000
> >  369  ENTRIES QUALIFIED
> >  >F CLIENT-EMP-NUM = "00022@"
> >  0  ENTRIES QUALIFIED
...
> The only legal form of "wildcarding" for a numeric item is an "in-between" or
> "greater than/less than" form of relational operator, which Query properly
> supported in the example given above.

Quite right...the B-Tree DBFIND looks for "@" only for X and U items.
For any other kind of B-Tree DBFIND, you have to use something other than
mode 1...which I would hope QUERY would do on your first example.
(The other modes allow <, <=, =, >=, >, and [], IIRC)

BTW, maybe someone should submit a bug report against QUERY...
F CLIENT-EMP-NUM = "00022@" shouldn't be allowed if CLIENT-EMP-NUM is
a Z12 field...the "@" isn't a valid digit (or sign).
If QUERY had properly reported that to Shawn, he'd have quickly realized
that the "@" wasn't close to what he wanted.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html

ATOM RSS1 RSS2