Kevin Toppenberg wrote:
Wow. That's good information. I thought that the
sorting was from the output. Like when you print a
file, how do you want the output sorted.
That is how it works, if an index can't be used. If you have more than
one sort level or you use a computed _expression_ on the SORT BY, then
the sort order of the report has to be built in the ^UTILITY($J global
and the index is ignored. (There are times when you can use an index,
but not affect the sorting of the report. This is a technique to
identify a subset of records to be sorted.)
Regarding indexes, I have found in the data
dictionary, that a given field may have many different
indexes. How would one, or the search program, know
what to use.
It would use the one that is useful for sorting - the Regular style
Index. The KWIC style is useless for sorting a report. Triggers,
Bulletin, etc. are irrelevant.
You said that this is determined by the
SORT BY parameter. How does this work and how would a
user specify the index to use?
You just specify the SORT BY: criteria and FM will take care of finding
indexes it can use. It is automatic.
Thanks
Kevin
--- 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
reentered
value for ENTERED BY field. I entered
'kst', and
it
expanded to 'TOPPENBERG, KEVIN S' (By the
way,
kst's
DUZ=73)
I then looked at the data with VPE's VGL
function.
Here it is. You can see that node;piece
13;2
(field
1302=ENTERED BY) here = 73 (Also, I looked
at the
global data for other documents that I had
not
re-entered, and they also were 73.)
=== 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
|
