I agree with you that the root of the problem here is that pointer
fields are not compared using the IEN but the name of the record. The
output transform may be the immediate source of the problem, but it
simply underscores the nature of the problem. Perhaps this is a case of
Fileman behaving in a way that is counterintuitive to programmers, but
perhaps not so to many users. It's really very similar to the situation
that occurs in many programming languages. If strings are reference
types, then you might expect strings having the same value (say,
"hello") to be equal, even if they are references to different (though
equivalent) objects. In some languages, the equality operator is
overloaded to deal with precisely this kind of situation.
In any case, I think it's a mistake to try to say whether records
should be compared using some notion of equivalence (in this case,
having the same name) or identity (same IEN). Rather, I think the right
thing to do would be to support different operators for each of these
scenarions, because in some cases one meaning will be what is required
and in others, it will be the other.
--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
> 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: <[email protected]>
> > > > >>>>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:
> > <[email protected]>
> > > > >>>>>>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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
A practical man is a man who practices the errors of his forefathers.
--Benjamin Disraeli
====
Greg Woodhouse
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
