The issue is not simply recompiling the CLI for 64-bit; I assume you want the tested reliability of SQLite.
"The [SQLite] project has 787 times as much test code and test scripts" as it does source code for the executable. https://www.sqlite.org/testing.html Running the exact same tests would not be enough, because you (and I) would want special tests for larger than 4 GB RAM. So, additional tests would have to be developed. So, I see three alternate solutions: 1. Find a corporate sponsor to fund development of 64-bit SQLite CLI 2. Remove some tables from memory (though it sounds like your difficulties are caused by recursion rather than the size of the raw data) 3. Use SQLite for persistent storage but move the in memory (tree navigation) operations to another (open source) language such as C, Java, Python or R (or the new Julia language that is approaching version 1.0) that has interfaces for SQLite and a 64-bit build for Windows. You will probably need another language to display the output anyway why not take advantage of Python, R or Julia? Even if you move to another language, you may find that your problem is recursion. In my experience, computer science textbooks give elegant examples using recursion, but then say the solution is not scale-able and give a less elegant solution using iterative techniques. Jim Callahan Data Scientist Orlando, FL On Tue, Aug 9, 2016 at 10:31 AM, Rousselot, Richard A < richard.a.rousse...@centurylink.com> wrote: > I would like to request a SQLite official 64-bit SQLite3.exe CLI (not DLL) > be created. > > I have reviewed the prior discussions regarding 64-bit SQLite3 and the > reasoning for which why creating a 64-bit version is denied are "it does > not make a real difference", "you can just use ram disks", etc., etc. > > Here is my plea... I am using a set of complicated CTEs to crawl through > a network (tree) to aggregate and calculate formulas. I don't have > exceptionally large datasets but my CTEs result in a ton of memory usage. > The process works well from disk, in Windows, but using a smaller test > sample I get about a 30% to 40% increase in processing time if I set the > PRAGMA to temp_store = 2. If I use a normal dataset, not a small test, I > hit an approximate 2G limit and get a "out of memory" message, which I > understand is due to SQLite3.exe being 32-bit. I have found some 3rd party > 64-bit builds for SQLite3 (best found is 3.8.5) but they are out of date > and don't allow all functionality that I am using. So, I do have a use > case that requires 64-bit and I would see a significant increase in speed. > > As to RAM disks, I work in a corporate environment that locks down user > rights which precludes me from distributing a tool that requires the > creation of a tool that needs administrator rights. I also, would like to > avoid having to compile it myself; I am not a software engineer. > > Thanks for your consideration. > > Richard > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
