close books

[John Ralls]

On Dec 9, 2010, at 8:53 AM, John A. Mason wrote:

> You know I never made that connection.... January 1 is already a holiday, so no bank account or statement should have Jan 1 listed with any transactions! I wouldn't have to move any transactions around or reschedule transfers to keep Dec 31 clean, I could just use Jan 1! brilliant!
>> I would however in time like to remove from main file all the
>> transactions older than two years, and thereby reduce its size.   In
>> sqlite would it be possible to do easily, as I understand is what you
>> are suggesting in the last sentence of your post quoted above?
> 
> The sqlite format means it is stored in a SQL-based database accessible file, thanks to the sqlite database engine. So thus, all it takes is a quick brush up on your SQL syntax and you can use the sqlite tools to do almost anything you want to the entries. And yes, that is what I do about every 6 months. I have a quick sql statement I run that makes a new record in all expense, income, etc. accounts with the TOTAL of all previous entries to that date, then it removes all the old transactions. That way I can still keep the running totals going, but I don't have to worry about anything getting too big. But note: I don't do this for a long time AFTER I close the period. For some of of the books I do, I close the periods each month... but I don't do any clearing for anything younger than say, 5 years.

Don't do that, at least not with 2.3/4. The sql store knows nothing about relations or constraints in this version: All of that is done in C in gnucash. What's more, a critical part of gnucash data, KVP slots, are not accessible with pure sql (the data are linked in a recursive hierarchy, so the retrieval and storage queries must be performed under program control.) 

If you want to mess with Gnucash's data outside of Gnucash, there are scheme and python bindings which will use gnucash's qof library to safely and correctly manipulate the data. Use them.

Regards,
John Ralls