[linas@linas.org: Re: [SQL-Ledger-users] OT: Web-based Checking Software]

cbbrowne@hex.net cbbrowne@hex.net
Thu, 03 May 2001 21:22:01 -0500

On Thu, 03 May 2001 20:19:27 CDT, the world broke into rejoicing as
linas@linas.org (Linas Vepstas)  said:
> List-Archive: <http://lists.sourceforge.net/archives//sql-ledger-users/>
> On Thu, May 03, 2001 at 04:37:12PM -0700, Roderick A. Anderson was heard 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.
> 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=20
> single-user mode, but has difficulties in multi-user mode.
> If you do debate this further, please cc. the gnucash-devel@gnucash.org
> mailing list.

I've been trying out SQL-Ledger recently.  [Aside: Looking at doin'
some writing for fun and profit.]

Pretty slick.  Simple, but slick.

The problem with interfacing GnuCash with SQL-Ledger will be that
they've got quite _vastly_ different data models.  The GnuCash tables
tie together via GUIDs, whilst SQL-Ledger ties together data in A/R,
A/P, Inventory, and G/L.  While SQL-Ledger has a somewhat more
sophisticated set of journals, the data _in_ the tables for GnuCash
looks a lot fancier, particularly in terms of commodity handling.

I could see writing code to translate GnuCash data from its SQL form
into SQL-Ledger's form (or vice-versa).  This would require having a
translation table to indicate how to translate account information
between the respective account "trees."  (Note that the translation is
not forcibly invertable...)  That's not going to be standardized; it
would different for your configuration versus mine.

One thing that SQL-Ledger "buys" is that it basically does database
queries on demand; _no_ need for the "event notification" that makes
the GnuCash Register a fairly hairy chunk of code.  That is, if you
make a change to a bit of data, the view of the register doesn't
automagically get updated.  And you don't get to see more than one
transaction's data at a time.

That difference has the "negative" implication that SQL-Ledger doesn't
provide "friendly, dynamic" views.  You only get to closely look at
one transaction at a time, and if you fiddle the date, the transaction
doesn't "magically" move to another spot on the screen, and balances
don't change.

On the other hand, there's not the complex register code.  It's pretty
easy to write an HTML screen to edit one transaction at a time.
Furthermore, there's the merit that SQL-Ledger is a _LOT_ easier to
make play well as a multi-user application, because there's no vast
interlocking set of event notifications to worry about.
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
Rules of  the Evil  Overlord #148. "Before  ridiculing my  enemies for
wasting time  on a device  to stop me  that couldn't possibly  work, I
will first acquire a copy of the schematics and make sure that in fact
it couldn't possibly work."  <http://www.eviloverlord.com/>