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