Hi Markus,
There has actually been some recent discussion on the mailing list
about setFirstResult() and setMaxResult(). Here's how they work:
The current implementation of setFirstResult() and setMaxResult() make
use of JDBC constructs rather than RDBMS constructs.
For setMaxResult() we call the java.sql.Statement.setMaxRows(int) method.
For setFirstResult() we make use of the ResultSet that is returned in
JDBC. If firstResult is set, we build query that returns a
TYPE_SCROLL_INSENSITIVE ResultSet and call resultSet.absolute(int) on
that result set.
Is it possible the result for the SQLAnywhere driver is not what we expect?
-Tom
Markus KARG wrote:
>When I was implementing the SQLAnywhere platform I remarked a failing
>test: complexResultPropertiesTest. That test tries three things:
>setFirstResult, setMaxResult and a combination of both. The used table
>holds 15 row. The first test (setFirstResult(2)) return 13 rows (what is
>correct, since 15-2=13). The second test (setMaxResults(15-1)) returns
>14 rows (what is correct, since 15-1=14). But the third test fails. The
>correct result would be to return 12 rows (= 15-2-1). But the actual
>result is 13 rows!
>
>I have not seen any faulty SQL (in fact, it seems that TopLink does this
>internally -- it does not apply any "SELECT TOP START AT" range
>constraints to the SQL, but seems to process the range constraints
>internally.
>
>So did I detect a bug in TopLink, or where is there a fault in my
>platform implementation?
>
>Thanks
>Markus
>
>