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