Might this not be a "reverse_unordered_selects" pragma or compile option going wrong, or at least the code making it work getting
somehow hooked in the new versions for this query?
I have seen similar things when using that pragma (but of course that was
intended).
Just a thought...
On 2015/01/19 16:27, Richard Hipp wrote:
Ignore my previous email on this subject. We are able to get
different results from 3.8.6 and 3.8.8. Unclear yet if the one or the
other is incorrect.
On 1/19/15, Richard Hipp <d...@sqlite.org> wrote:
On 1/19/15, Angelo Mottola <a.mott...@converge.it> wrote:
Hello,
I have a regression to report, that seems to have been introduced between
SQLite 3.8.6 and the newest 3.8.8 (at least our test case worked in 3.8.6
and stopped working somewhere in 3.8.7.x; we were hoping it got fixed in
3.8.8 but eventually it wasn’t).
...
The query worked correctly with SQLite 3.8.6, returning for our test-case
database 5 records with the same EB_DocumentiFiscali__00.NumeroInterno,
ordered by EB_RigheDocFiscali.NumeroRiga in ascending order.
With 3.8.7 and 3.8.8 however, the very same query returns the same 5
records
but in the wrong order, as if it was ordered by NumeroRiga DESC (instead
of
ASC). What’s even more strange is the fact that if you remove the LIMIT
clause, the records are returned in the correct order even with 3.8.7 and
3.8.8.
I downloaded your test database and ran your query on 3.8.6, 3.8.7.4,
and 3.8.8. All three give the same answer for me. Dan did likewise
with the same results, and in addition ran the test under valgrind
with no warnings issued.
Unable to recreate the problem.
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
