From: <li...@li...> - 2001-05-04 16:42:36
|
Hi John, On Fri, May 04, 2001 at 10:34:31AM -0500, John Foster was heard to remark: > Linas Vepstas wrote: > >=20 > > On Thu, May 03, 2001 at 04:37:12PM -0700, Roderick A. Anderson was hear= d to remark: > > > Slightly off topic but I'm looking for check book software. I'm > > > currently using GnuCash which is nice but I haven't found a reasonable > > > way to tie into SQL-Ledger. So I'm hoping someone knows of some > > > web-based software. Probably, needless to say, but perl based, and > > > using PostgreSQL (or other DBI based method) it preferred. > >=20 > > If anyone can help the gnucash developers in figuring out how to tie > > into sql-ledger (and/or writing the code to do the same) that would be > > great. BTW, gnucash has a a beta postgres backend. It works fine in > > single-user mode, but has difficulties in multi-user mode. > >=20 > > If you do debate this further, please cc. the gnu...@gn... > > mailing list. > >=20 > > --linas > -------------------------------------------------------------- > Hi Linas! I recently suggested that SQL-Ledger incorporate the ability > to import/export ".qif" style files directly into its database. That may > not be the best solution, but by putting a table or tables in place that The QIF format is a nasty, nasty format that is very hard to handle correctly. For example, it fails to denote the currency. So, for example, say you export a transaction for 100. Thats what, 100 dollars? pesos? widgets in stock? Thats only the crowd-warmer for the stock of sick jokes that QIF has in store ... > handle bank related functions it would be possible to use gnucash or > moneydance (or most other money management systems) to include realtime > cash management functions into SQL-Ledger. I am very weak in postgresql > skills, there may be a way to do the same thing from some postgresql > management system. I have also proposed that to the developers at > Webmin. Note that gnucash has a prototype xml protocol for querying a server to get the financial data it displays. There might be a way of stapling that into sql-ledger, and then one gets the live data manipulation, reports, etc.=20 (There is also an rpc backend ... lets talk more if this get serious). > If/when the beta gnucash with a postgresql backend becomes stable in a > multiuser environment=20 Well, its 'almost' usable, except for one interesting technical problem I'd like to tell you about. GnuCash likes to display accounts in a 'checkbook register style': that means that there is a running balance displayed in one of the columns (far right column). Say one has a millions transactions in the database. Clearly its insane to fetch all of them to compute a running balance. We could store a running balance with each transaction, but this has a nasty update semantic: changing one transaction would require updates to hundreds or thousands of others that occur at a later date. We talked about storing 'balance checkpoints' to solve that problem. But this introduces another problem: I would need to query a contiguous set of transactions between checkpoints. At this point, the sql queries start getting complex, there's a lot of traffic to the database, and yuck, so we left it to ferment a bit more. If you are willing to ignore the running balance column, then I think the multi-user mode is not far off. (there's some minor misc stuff that needs to be brushed up, I forget what). > the procedure becomes simply a matter of using a > single incorporated database that has all of the tables necessary. ( a > dream come true) Uh, not quite. You could put all the tables in one database, but so what? Unless you modified some code somewhere, you'd still have to enter any giving transaction twice, by hand. The gnucash sql tables are no doubt quite different than the sql-ledger tables. > This is very important to me as it is an integral part of the > development of a complete retail environment using only open source Ohh. ahh. Let me just say that I'd like to have gnucash develop more/better sophisitcated capabilites, and I'd rather do so in cooperation with sql-ledger, than in competition. I think we can accomplish more if we can avoid re-inventing each-others core features. --linas > software. Please cc: jf...@au... with any discussion on this.= =20 > Thanks. > John Foster --=20 Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/ |