Ok, so given below, this is what I understand to be
happening. I will compare it to a date field, and
show that the pointer field is not working in a
consistent manner to date fields.
When the user inputs a date, the supplied external
format may be in one of several formats, e.g. Jan 1,
2005 or 1/1/05. This must be converted to an internal
format. This converted user-input value must then be
compared against the database. If the two
fileman-formated values are the same, the match is
successful. Note, that the database value is NOT
coverted to an external form and THEN compared. If
so, the program would have to compare the text of
"1/1/05" with "January 1, 2005" -- which would not be
a match.
So the comparison is done in the format that the value
is stored in the database.
Now extend this to pointer fields. The user may
supply the search value in a variety of ways. In my
case, the request for an entry from file# 200 can be
entered as "kst" or "TOPPEN,K" OR "TOPPENBERG,KEVIN"
etc. This value is then converted to a record
number/IEN/DUZ#, say 70. What should happen is that
the value 70 is compared against the database entry
(in RecNum/IEN/#DUZ format). If the database held 70,
we have a match.
Instead, the search program is asking for an output
transform to transform the record number into a text
string. It is then comparing this to the user's
input. So when the output transform is S Y="ABRA
KADABRA", then THIS is the value compared to the user
input.
Thus the way that dates and pointer fields are handled
is inconsistent. And I think my earlier posting is a
straightforward example of the problems this can
cause.
Again, the "bug" word is probably too strong. But I
think the program could be made to be better if
pointer fields were treated like date fields.
Kevin
--- Greg Woodhouse <[EMAIL PROTECTED]> wrote:
> I was wrong. When there is no index on the pointer
> field (even if there
> is an output transform) Fileman handles the lookup
> properly in the
> search dialog. That's not the problem.
>
> But if I an output transform of
>
> S Y="ABRA KADABRA"
>
> the search suddenly fails (though the lookup
> succeeds).
>
> --- Greg Woodhouse <[EMAIL PROTECTED]> wrote:
>
> > That was my understanding, but consider thhat the
> basic symptom is
> > that
> > we are comparing a pointer field for equality
> after doing a lookup
> > (selection after entering the '=' condition), but
> Fileman fails to
> > find
> > a value when entering one lookup value ("kst"),
> but it does succeed
> > when entering the .01 value.
> >
> > I'm not suggesting that the SEARCH uses and index,
> but that the user
> > dialog makes use of an index when looking up a
> pointer value for
> > comparision purposes. I'll have to try it out
> under another scenario
> > and see if this occurs consistently.
> >
> > --- Greg Kreis <[EMAIL PROTECTED]> wrote:
> >
> > > The A, B, C conditions don't use an index. They
> are 'if'
> > statements
> > > that are applied to records that are found by
> the SORT BY part of
> > the
> > >
> > > Search. Now, depending on how the SORT BY is
> constructed, it can
> > use
> > > an
> > > index or simply order through all the records of
> the file in record
> > > order.
> > >
> > > Kevin Toppenberg wrote:
> > >
> > > >Is the search dependant on an index? What if I
> were
> > > >to define a file that did not have an index.
> Would it
> > > >not be searchable? I thought it was sweeping
> through
> > > >all records in the given file.
> > > >
> > > >Regarding the DIC("PTRIX"), surely the end user
> is not
> > > >expected to do this...(?)
> > > >
> > > >Thanks
> > > >Kevin
> > > >
> > > >--- Greg Woodhouse <[EMAIL PROTECTED]>
> wrote:
> > > >
> > > >
> > > >
> > > >>My guess is that Fileman in looking in the "B"
> > > >>cross-reference for
> > > >>"kst" and not finding it. When doing a DIC
> lookup, I
> > > >>think you need to
> > > >>set DIC("PTRIX") (I'm going by memory) if you
> want
> > > >>to look up a
> > > >>"pointed to" value using a different index.
> > > >>
> > > >>--- Greg Woodhouse <[EMAIL PROTECTED]>
> wrote:
> > > >>
> > > >>
> > > >>
> > > >>>It would still be interesting to know if the
> > > >>>
> > > >>>
> > > >>search fails when
> > > >>
> > > >>
> > > >>>entereing "TOPPENBERG, KEVIN" instead of
> "kst".
> > > >>>
> > > >>>
> > > >>>--- Lloyd Milligan <[EMAIL PROTECTED]>
> wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Something about the ENTERED BY field DD
> seems to
> > > >>>>
> > > >>>>
> > > >>prevent the search
> > > >>
> > > >>
> > > >>>>from
> > > >>>>working as expected. As you pointed out,
> > > >>>>
> > > >>>>
> > > >>initials are a valid
> > > >>
> > > >>
> > > >>>lookup
> > > >>>
> > > >>>
> > > >>>>value.
> > > >>>>So why doesn't this work?
> > > >>>>
> > > >>>>Lloyd
> > > >>>>
> > > >>>>----- Original Message -----
> > > >>>>From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
> > > >>>>To: <hardhats-members@lists.sourceforge.net>
> > > >>>>Sent: Sunday, March 20, 2005 8:33 AM
> > > >>>>Subject: Re: [Hardhats-members] Another
> example
> > > >>>>
> > > >>>>
> > > >>of Fileman Search
> > > >>
> > > >>
> > > >>>>being
> > > >>>>unreliable
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>Ok, that does work.
> > > >>>>>
> > > >>>>>But as far as I am concerned, THIS IS A
> BUG!
> > > >>>>>
> > > >>>>>Any reasonable user (and seasoned Fileman
> > > >>>>>
> > > >>>>>
> > > >>users on
> > > >>
> > > >>
> > > >>>>>this board) can't figure this out.
> > > >>>>>
> > > >>>>>Kevin
> > > >>>>>
> > > >>>>>--- Lloyd Milligan <[EMAIL PROTECTED]>
> > > >>>>>
> > > >>>>>
> > > >>wrote:
> > > >>
> > > >>
> > > >>>>>>This has something to do with initials
> being
> > > >>>>>>
> > > >>>>>>
> > > >>an
> > > >>
> > > >>
> > > >>>>>>output transform. If you
> > > >>>>>>use INTERNAL(ENTERED BY), EQUALS, 73 it
> > > >>>>>>
> > > >>>>>>
> > > >>should work.
> > > >>
> > > >>
> > > >>>>>>Lloyd
> > > >>>>>>
> > > >>>>>>----- Original Message -----
> > > >>>>>>From: "Kevin Toppenberg"
> <[EMAIL PROTECTED]>
> > > >>>>>>To:
> <hardhats-members@lists.sourceforge.net>
> > > >>>>>>Sent: Sunday, March 20, 2005 7:59 AM
> > > >>>>>>Subject: Re: [Hardhats-members] Another
> > > >>>>>>
> > > >>>>>>
> > > >>example of
> > > >>
> > > >>
> > > >>>>>>Fileman Search being
> > > >>>>>>unreliable
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>Still doesn't work.
> > > >>>>>>>
> > > >>>>>>>I went back to that particular record,
> and
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
