saved to a SQL server, now it won't load it

[John Ralls]

> On Feb 18, 2017, at 10:26 PM, George Riner <georgeriner at mycogeo.com> wrote:
> 
> Thanks for the tip.  I now see that gc sends several giant sql statements, a bit over 1.36 million characters long each, to the server to load things by guid from the slots table.  The server is choking/refusing. Setting the max_allowed_packet size to something larger (say, 2,097,152) allows the sql to process.  GC now loads the books from the db, but it's really slower than loading the same data from a local '.gnucash' file.  Maybe there's db tuning that could be done on the server to improve performance... or GC has some features for tuning its performance (I'm windows 10 64-bit)...  For the time being, I'm sticking with the 4.5 Mb .gnucash file on my local drive which *only* takes 50 seconds to load.
> 
> As noted in a 2011 posting here: https://lists.gnucash.org/pipermail/gnucash-user/2011-October/041336.html
> where the user, like me, has data (imported and cleaned up from Quicken) going back to 1993.


Ah, good detective work.

It's always going to load faster from a local drive than over the wire. That said, GnuCash's SQL backend design is rather naive and decidedly not tunable. I'm just finishing up the first phase of reworking it, which is converting it from somewhat impenetrable C to more easily understandable and more modular C++.  Unfortunately we have to shift our efforts to removing the WebKit1 dependency because several distros are pulling it for security reasons that don't affect GnuCash so not nuch more is likely to happen before the 2.8.0 release at the end of the year.

Regards,
John Ralls