@Greg OLone I'm still not convinced.
1. It works on Windows (said Robin in the Feedback report)
2. If it were some kind of threshold error (notice point 1 proves it isn't), that shouldn't crash, it should return an error (said all programmers everywhere)
What more convincing is needed? The fact that it crashes on Mac and Linux, but not on Windows, seems like pretty clear evidence that this must be a problem with the way the library is compiled for Mac and Linux (since probably these platforms use the same library). I said in the OP that I had checked the SQLite docs for limits on returned query size and it looks like there is none. Others have tested and showed there doesn't seem to be a limit. And even if there is a limit, if that limit is overstepped, that shouldn't result in a crash, it should return an error.
I've just done a bunch of tests and have made a some observations based on the project on the submitted feedback case:
- The size of the result sets that crash on my machine are right around 1GB. That is, 13107199 records with a size of ~81 bytes per record.
- I did a test and inserted the same data into Max1 and Max2 as was put in Points and the results were nearly identical.
It seems to me that sqlite may have a 1GB memory limit on returned recordsets, although I can find no documentation to that effect.
FWIW, You can get around this by doing multiple queries using the LIMIT and OFFSET directives to return groups of records at a time, so instead of:
SELECT * FROM S67
You would use:
SELECT * FROM S67 LIMIT 10000000 OFFSET 0;
and increase the offset by the number of records you requested the previous time.
SELECT * FROM S67 LIMIT 10000000 OFFSET 10000000;
SELECT * FROM S67 LIMIT 10000000 OFFSET 20000000;
I appreciate that., and I'm aware of this possibility, but the method doesn't provide one recordset, so it doesn't solve the problem. For obvious reasons, the recordset object doesn't allow merging several objects into one, so the workaround doesn't do what SELECT * without LIMIT and OFFSET does.