Lance J. Andersen schrieb:
> Markus,
>
> Which JDBC driver are you using? jConnect or the SQL Anywhere driver
> which uses the jdbc-odbc bridge?
Lance,
the SQLAnywherePlatform that I implemented is targetting the usage of
the iAnywhere driver (Sybase's JDBC-ODBC bridge). While beeing not
platform independent, it provides superior performance compared to
jConnect, and is the official recommendation of Sybase.
Regards
Markus
>
>
> Markus KARG wrote:
>> Tom,
>>
>> I had been using absolute(x) in the past with SQLAnywhere and it
>> worked well always. If you send me a few (at least abstract) code
>> lines then I will try them out.
>>
>> Thanks
>> Markus
>>
>> Tom Ware schrieb:
>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>