Hi,

I'm using Elevate 2.04B4 and seeing some weird behaviour when combining a RANGE clause with a dataset filter.

Lets say I have a 1000 product records where the ProductName begins with 'L' - see below query.
You can make an assumption that a single product can come from multiple suppliers.

SELECT ProductName, SupplierName, Product.PreferredFlag
FROM Product
INNER JOIN Supplier ON Supplier.ProductCode = Product.ProductCode
WHERE ProductName LIKE 'L%'
ORDER BY ProductName, SupplierName
RANGE 1 to 200

I'm trying to locate the first record where PreferredFlag = True (in the ProductName,SupplierName order)
So I apply a dataset filter (PreferredFlag = True), go to the first record, take a bookmark, remove the filter and go to that bookmark.

However, if the first preferred record is outside of the 1 - 200 range of the original recordset, the GotoBookmark fails with a message - Record not found

Apparently elevate applies the range AFTER filtering the records. What I'm saying is that by applying the filter I suddenly find records that were not in the original range. Is this as designed?

Cheers,
Chris B

Chris,

<< I'm trying to locate the first record where PreferredFlag = True (in the
ProductName,SupplierName order) So I apply a dataset filter (PreferredFlag =
True), go to the first record, take a bookmark, remove the filter and go to
that bookmark.

However, if the first preferred record is outside of the 1 - 200 range of
the original recordset, the GotoBookmark fails with a message - Record not
found

Apparently elevate applies the range AFTER filtering the records. What I'm
saying is that by applying the filter I suddenly find records that were not
in the original range. Is this as designed? >>

Yes, although it can seem weird, it is operating according to design.
However, in this case the result of the design is more accidental than
anything.
Numeric ranges are handled dynamically like key value ranges, and always
*after* any expression filters, so combining them with expression filters on
the result set (after the initial query execution) can result in rows
showing up in the range that weren't originally there.

I can see about making sure that user-defined expression filters are
evaluated *after* the ranges.  The whole filtering system internally works
on a ranking system that first looks at the type of filter (expression, key
value range, sequential range), and then looks at the optimization level of
each filter.

--
Tim Young
Elevate Software
www.elevatesoft.com

I'm very surprised by this, and I believe that filtering should always be after a result set has been filled, so if nothing else a property in TEDBQuery would be the sanest way to proceed.