So again, to simplify this for my benefit, we have:
1. input of "kst" --> IEN=73
2. IEN of 73 in File#200="TOPPENBERG,KEVIN"
3. because "kst"<>"TOPPENBERG,KEVIN" match fails.
This is especially frustrating because it expands
"kst" to TOPPENBERG,KEVIN But apparently is either
comparing 73 to TOPPENBERG,KEVIN or comparing "kst" to
TOPPENBERG,KEVIN.
Needs a fix.
Kevin
--- steven mcphelan <[EMAIL PROTECTED]> wrote:
> With equals, the lookup is done and resolved to a
> pointer in the Conditions
> prompt. When the search is actually performed, it
> compares the .01 field
> value of the pointed to file to the value of the
> field in the original file.
> Since that field has an output transform, the TIU
> field external value does
> not equal the external value of the pointed to file
> entry and thus no
> matches are found. However you select the lookup
> entry in the search
> condition portion is irrelevant.
>
> ----- Original Message -----
> From: "Greg Woodhouse" <[EMAIL PROTECTED]>
> To: <hardhats-members@lists.sourceforge.net>
> Sent: Monday, March 21, 2005 12:49 AM
> Subject: Re: [Hardhats-members] Another example of
> Fileman Search being
> unreliable
>
>
> > I should apologize for being a bit behind the
> curve on this one. When I
> > initially suggested using "=" instead of "equals",
> it's because I was
> > wondering if it might result in a lookup by IEN
> without using INTERNAL.
> > I guess I should have just looked it up.
> >
> >
> > --- 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.
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------
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
