I'm sorry... Maybe I wasn't clear enough... Let me try it again..


First, the table I'm using has over 10k of records. But of the 10k
only only 1-2 k is actually active. For historical reasons.. I have
a field called ACTIVESTATUS with either Y or N value.

The problem I'm getting is not directly with the orderlinks.. I have
no problem with that on startup.

The real problem is that if I use orderlink to speed up locates or
other things, it seems to TOTALY IGNORE the WHERE clause parameter.

See, if I open the table with an orderlink with pos=1 , pos=10 , or
any pos, everything opens fine. The problem ONLY occurs when I
press the REFRESH BUTTON. If I don't press refresh, it seems to work
alright. And it only occurs if the current record that I'm pressing
the refresh button is following a record that is not part of the where
clause. Which leads me to believe that this is a problem when using
where clause with orderlinks.

I can understand that orderlink can return the wronge result if used
incorrectly, but it should never ignore the where clause parameter.
Which is the problem I seem to be getting.

If your telling me that the orderlink POS will always ignore the where
clause of a SQL, then I will not use this feature. But to my
understanding, it should always use the where clause.

Also, I've tried using the orderlinks on a String field or a Integer
field, Both seem to do the seem to have the same result. Records that
are outside of the where clause still appear.

If your still unclear of what I'm talking about, I can try to
reproduce a simple small version with the same problem.

Thanks,


Have a nice day.

--- In IBObjects@yahoogroups.com, "Jason Wharton" <jwharton@i...> wrote:
> If you have only 4 records in your table or results of the query then I
> recommend you do NOT use the POS attribute of OrderingLinks. This is a
> feature designed for very large datasets.
>
> Also, by putting the POS attribute value to 1 you are causing it to
focus on
> one character length. When dealing with numeric columns I don't
recommend
> you use this feature unless you are locked into a series of digits
that will
> always have the same number of digits, avoiding leading zeros. Then,
you can
> set the POS attribute value to match the number of digits. This way
it will
> all work together well. Otherwise, confusing results will develop with
> numerics.
>
> HTH,
> Jason Wharton
>