linking errors

[T.Pospisek's MailLists]

This is btw. with Robert's Debian g-wrap package, so the error -might-
also be there.

Has anybody else seen this?
*t

../../src/engine/obj/Session.o: In function `xaccSessionBeginSQL':
/home/tpo/ftp/gnucash/cvs/gnucash/src/engine/Session.c:200: undefined
reference to `pgendNew'
/home/tpo/ftp/gnucash/cvs/gnucash/src/engine/Session.c:209: undefined
reference to `xaccGroupSetBackend'
../../src/engine/obj/Transaction.o: In function `xaccTransCommitEdit':
/home/tpo/ftp/gnucash/cvs/gnucash/src/engine/Transaction.c:1066: undefined
reference to `xaccTransactionGetBackend'
collect2: ld returned 1 exit status


 Tomas Pospisek - Freelance: Linuxing, Networking
   http://spin.ch/~tpo/freelance

Re: on-line banking & qif import

[Richard Wackerbarth]

On Sun, 14 May 2000, Hendrik Boom wrote:
My question was
> > "With respect to reconciliation, when is the 'payee' field considered to
> > be reconciled?"
>
> I guess I missed your point because I don't understand what it means
> to reconcile a 'payee' field.

One aspect of reconciliation is the immutability of the entry. When do we 
declare that we have verified that the Payee is correct and prohibit ordinary 
alterations to it.

Re: linking errors

[Dave Peticolas]

> This is btw. with Robert's Debian g-wrap package, so the error -might-
> also be there.
> 
> Has anybody else seen this?
> *t
 
This should be fixed.

dave

Re: Improved g-wrap packaging now available

[T.Pospisek's MailLists]

On Mon, 15 May 2000, Robert Graham Merkel wrote:

> Bang on them a bit please!

Works perfectly, no problems found until now.
*t


 Tomas Pospisek - Freelance: Linuxing, Networking
   http://spin.ch/~tpo/freelance

Strange bug with split transactions

[Dylan Paul Thurston]

I recently came across a strange bug with split transactions and the
auto-single line display in GnuCash 1.3.7.  A vendor billed my account
in two separate transactions for a single order.  Since I wanted to
clear them separately, I created a split transaction.  The two journal
entries naturally ended up right next to each other in the other
ledger (in the opposite order than I expected).  In the Auto-single
mode, I was unable to select the second JE on the screen: clicking on
it sent the cursor into the first JE.

Best,
Dylan Thurston

Multiple currencies

[Tamas Nagy]

Is there any way to change the balance currency in the main window to other
than USD?

Tamas Nagy

"Best things in life are free..."
Member of KOCR Team
E-mail: [EMAIL PROTECTED]
Web: http:/www.tar.hu/nagytam

Fwd: About Berkeley DB

[Alessio Bragadini]

Since it's closely related to the discussion we've had about a proper
DB backend, I am forwarding this lengthy message from the PostgreSql
development mailing list.

 Original Message 
Subject: [HACKERS] Proposal: replace no-overwrite with Berkeley DB
Date: Sun, 14 May 2000 23:15:06 -0700
From: "Michael A. Olson" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]

Hi,

My name is Mike Olson.  I worked on Postgres at UC Berkeley from 1988
until 1993, when I left grad school to join Illustra.  I did much of
the access method design, and a bunch of implementation in the btree
and rtree code.  I did a lot of work in storage management, and in
the bowels of the system generally.

I haven't looked at PostgreSQL since Jolly Chen and Andrew Yu shipped
the last version from Berkeley, but I've followed the project from
a distance for several years.  My interest was piqued by last week's
announcement by Great Bridge that it would build a services company
around the Open Source project.

In the last couple of days, I've exchanged email with members of the
PostgreSQL core, and with Ned Lilly at Great Bridge.  I made a
proposal that Marc Fournier, Bruce Momjian, Tom Lane, and others
encouraged me to make to the community at large.  That's what I'm
doing now.

PostgreSQL uses the no-overwrite storage manager originally designed
at Berkeley as a part of the research project.  No-overwrite storage
was a great innovation, and led to a lot of interesting papers, but
it hasn't caught on in database systems generally.

There are several reasons for this.  No-overwrite storage offers two
features to users:

+  Time travel, so that you can see the database state at any
   arbitrary time in history, and

+  fast recovery, since you don't need to do log processing at
   restart time.

The first advantage isn't interesting to most people (when was the last
time you had to look at a record from 3pm last Wednesday?).  Even if
it *is* interesting, you have to run vacuum and sacrifice history from

time to time, or you'll wind up giving your entire operating budget
to Seagate for hard drives.

The second advantage doesn't really exist.  Most database systems offer
fast recovery using fairly simple techniques like periodic checkpoints.
Administrators can bound recovery time as tightly as they need to
without using no-overwrite.

And no-overwrite storage has some serious disadvantages.  You need to
keep the file of commit status for every transaction around forever.
Over time, the file will grow to be gigabytes in size.  We actually
had a customer at Illustra who was low on space and deleted it manually.
That's a good way to sell support contracts, but a bad way to keep
customers.  Worse, no-overwrite forces a lot of random I/O instead of
the simple sequential writes that logging systems do.  Every update has
to write the new record and update the t_xmax field of the old record
in place.

I understand that there is already some work underway to replace the
no-overwrite storage manager with a conventional system based on
write-ahead logging (WAL).  I think that that's a good idea, and I'm
glad to hear it's getting some thought.

My proposal to the core team was that they consider using Berkeley DB,
from Sleepycat Software, as the replacement storage manager for
Postgres.
I'll give you a technical summary of Berkeley DB in a minute, but first
I should give a little history.

When I was at Berkeley, my reimplementation of btrees for Postgres
actually marked the fifth time I'd had to write that facility from
scratch for some project or other.  I complained about that to my
office-mate, Margo Seltzer, who is now a professor at Harvard.  She
had a similar frustration with database libraries on ATT-derived
versions of UNIX -- she wanted to use hashing in an application she

was writing, but the different flavors or UNIX all supported different
hash packages with different interfaces.

In our copious spare time, we wrote the first version of Berkeley DB.
It provided single-user btrees and hashing.  It was included in 4.4BSD,
the Berkeley UNIX operating system release, and got used by a ton of
different Open Source and proprietary projects.

The original Berkeley DB code was written by people who knew Postgres
and the interfaces that it required very well.  The btree code in
particular was designed to just drop in and run in Postgres, though
we never took that step, for lack of time.

In 1996, Margo and Keith Bostic (Keith was one of the key people on
the BSD project) were approached by Netscape to add transactions,
logging, locking, and recovery to Berkeley DB.  Netscape was flush
with cash from the public markets, and could pay for the work.
Sleepycat Software was born, and a bit less than a year later,
version 2.0 of Berkeley DB shipped from Sleepycat.

We're at release 3.0 on the Web site now, and 3.1 will be out RSN.
The current version of Berkeley DB has these properties:

  

Re: Fwd: About Berkeley DB

[Richard Wackerbarth]

On Mon, 15 May 2000, Alessio Bragadini wrote:
> Since it's closely related to the discussion we've had about a proper
> DB backend, I am forwarding this lengthy message from the PostgreSql
> development mailing list.

I think that our discussion is more "Which do we want?"
a) Roll our own
b) Really integrate the store into a RDBM
c) Shim our engine to use any one of many stores.

How to implement really only applies to (a).

Re: gnucash 1.3.7 bugs.

[linas]

forward note to mailing list

It's been rumoured that Jon A. Christopher said:
> 
> 
> Hello,
> 
> I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> 6.2 system.  The Account reconcile window has the credits and debits
> columns reversed.
> 
> -Jon
> 
> -- 
> Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
> Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
> Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
> College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon
> 
> 

Re: gnucash 1.3.7 bugs.

[Dylan Paul Thurston]

On Mon, May 15, 2000 at 05:32:29PM -0500, [EMAIL PROTECTED] wrote:
> It's been rumoured that Jon A. Christopher said:
> > 
> > 
> > Hello,
> > 
> > I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> > 6.2 system.  The Account reconcile window has the credits and debits
> > columns reversed.

On my version of GnuCash 1.3.7 (compiled from source on a Debian woody
system), the credit and debit columns are reversed in many places,
including register windows.  It seems to only happen if the columns
are titled 'Debit' and 'Credit'.

--Dylan Thurston

Re: gnucash 1.3.7 bugs.

[Dave Peticolas]

> 
> I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> 6.2 system.  The Account reconcile window has the credits and debits
> columns reversed.
> 
> -Jon

Hi Jon, here is what happened. We recently discovered that we have
been using the terms 'debit' and 'credit' incorrectly in GnuCash.
In standard accounting practice, a debit is an increase in assets,
such as a deposit to a bank account, and a credit is a decrease in
assets, such as a payment, credit card charge, etc.

Starting in 1.3.7, we began using the terms according to the sense
above, thus the change in column position of items in the reconcile
window. I apologize for any confusion.

thanks,
dave

Re: cvs 2000-05-08

[Rob Browning]

Dave Peticolas <[EMAIL PROTECTED]> writes:

>  + Applied Rob Browning's patch to break out g-wrap.
> 
>NOTE 1: Before you update, remove src/guile/gnucash.h
>You can also delete lib/g-wrap, lib/g-wrap-install,
>and lib/g-wrap.configure.

Also, if you're using 

  cvs -z3 update -Pd

(and you should be), and you do a make clean before the update, I
think it'll probably DTRT anyhow.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: on-line banking & qif import

[Glen Ditchfield]

I'd like the looser rules for matching imported entries with existing entries. 

The .qif files I get from my bank contain descriptions like 
"CHQ#00452-0041093240" for a cheque.  I suppose the digits after the dash are
some sort of tracking number; at any rate, when I type the cheque into
Gnucash I can't predict what they will turn out to be. 

ATM withdrawal descriptions look like "GM W/D000915".  In this case I
do know what the trailing digits will be, but I don't want to type them or the
spaces, because I'm lazy.

Of course, for cheques and even some ATM withdrawals, the date in the .qif file
won't be the date on which I wrote the cheque or made the withdrawal.

For my purposes, I think I would like an existing entry in an account to match
an imported entry if 
- the amounts match,
- the existing entry's description is a prefix of the imported entry's
description, and
- the existing record's date is on or before the imported record's date.

Implementing the data directory (was Re: Fwd: About Berkeley DB)

[Rob Browning]

Alessio Bragadini <[EMAIL PROTECTED]> writes:

> Since it's closely related to the discussion we've had about a
> proper DB backend, I am forwarding this lengthy message from the
> PostgreSql development mailing list.

Very interesting.  I hadn't realized that their db had so much
functionality these days.  For those interested, see these two
pointers:

  http://www.sleepycat.com/docs/ref/intro/what.html
  http://www.sleepycat.com/docs/ref/intro/do.html

I've been working a bit on a "filestore API".  This is to allow us to
switch to storing all the data associated with a set of accounts as a
subdirectory rather than a single file.  We'd have one file in there
that stores the engine data that's in our current single data file,
and then we'd have other files for other things.

However, after poking around in the db docs (from now on, when I say
db here, I mean the sleepycat db), I'm wondering if this might be much
better candidate for that job than "rolling our own" fs subtree
approach.  For now, I'm putting aside the question of whether or not
we might want to break out the current engine data as db tables.  For
now I'm just interested in considering if using db might be the best
way to give us the "sectional data store".

Things to think about:

  - db supports a "subname" argument in the "open" call, so you can
have multiple db tables inside one file.  With even marginally
careful subnaming, we can use the db for all our "sectional
subfiles" right now, and still be able to break out the engine
data into tables later if we decide it's a good idea.

  - db appears to have industrial strength locking, transactions, and
logging with full recoverability if requested.

  - db has dump and load to/from text format file routines, so people
interested in a accessing their data in a text format will have a
well documented method.

  - has a threaded interface with an optional daemon for deadlock
detection and resolution (probably not that useful for us for a
long time).

  - db supports multiple readers/writers.

  - db supports hot backups using normal unix tools.  You can just
tar/cp/whatever your file while its open with no ill effects as
long as the app properly uses the built in transaction mechanism.

  - db seems to be extremely portable, which might be a substantial
bonus if we ever want to whip up a tiny embedded client for
handhelds or whatever.

  - db already has perl, python, tcl, java, c, and C++ interfaces.

So, now that I've listed a bunch of pluses, I'm sure there are people
out there with more experience than me with this db.  What are the
minuses?

Also, though this probably belongs as a separate discussion, and I
haven't thought heavily about it yet, what about actually using it as
our engine data storage format (i.e. splits as a subtable,
transactions as a subtable, accounts as a subtable, etc.)?  It's not
as sophisticated as SQL (though that's possibly a plus as much as a
minus) since it's only a one dimensional hash, but you can build
anything you want on top of that, and, as compared to our current
approach, it seems like it might be better across the board.
Of course, this question is orthogonal to whether or not it's the
right thing to use to implement the "sectional data store" for
non-engine data.

The nice thing is that if we do decide for now to just use it for our
non-engine data (where the engine data is just a binary "blob" stored
as one of the subnames in the database file), it should be a very
straightforward step to break out the engine data into sub-tables
later if that turns out to be a good idea.

Thoughts?

(Bracing for a long thread...)

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: on-line banking & qif import

[Christopher Browne]

On Mon, 15 May 2000 21:18:16 CDT, the world broke into rejoicing as
Glen Ditchfield <[EMAIL PROTECTED]>  said:
> I'd like the looser rules for matching imported entries with existing
>entries. 

Ouch.  I'm starting to get a tad concerned about how "fuzzy" this matching
is starting to get.

> The .qif files I get from my bank contain descriptions like 
> "CHQ#00452-0041093240" for a cheque.  I suppose the digits after the dash are
> some sort of tracking number; at any rate, when I type the cheque into
> Gnucash I can't predict what they will turn out to be. 
> 
> ATM withdrawal descriptions look like "GM W/D000915".  In this case I
> do know what the trailing digits will be, but I don't want to type
> them or the spaces, because I'm lazy.
> 
> Of course, for cheques and even some ATM withdrawals, the date in the
> .qif file won't be the date on which I wrote the cheque or made the
> withdrawal.

Indeed.

> For my purposes, I think I would like an existing entry in an account
> to match an imported entry if 
> - the amounts match,
> - the existing entry's description is a prefix of the imported entry's
> description, and
> - the existing record's date is on or before the imported record's date.

The problem is that this starts leading us towards the possibility of the
software deciding to throw out transactions because they _appear_ similar.
THAT would be a bad thing.

This sort of suggests that the system shouldn't quietly drop the
transactions, but rather list them in parallel [e.g. - side by side] and
provide the option of doing some combination of:
  a) Drop the one on the books in favor of the one being loaded,
  b) Drop the one being loaded,
  c) Keep both,
  d) [This starts getting questionable...] Merge data for the transactions
 together, say pulling all the non-blank fields from the input file
 in to replace what's in GnuCash.
--
If you  ever drop your  keys into a  river of molten lava,  let'em go,
because, man, they're gone.
[EMAIL PROTECTED] - 

Use of Sleepycat DB

[Christopher Browne]

On 15 May 2000 22:10:21 CDT, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]>  said:
> However, after poking around in the db docs (from now on, when I say
> db here, I mean the sleepycat db), I'm wondering if this might be much
> better candidate for that job than "rolling our own" fs subtree
> approach.  For now, I'm putting aside the question of whether or not
> we might want to break out the current engine data as db tables.  For
> now I'm just interested in considering if using db might be the best
> way to give us the "sectional data store".

Lots of "food for thought."

> Things to think about:
> 
>   - db supports a "subname" argument in the "open" call, so you can
> have multiple db tables inside one file.  With even marginally
> careful subnaming, we can use the db for all our "sectional
> subfiles" right now, and still be able to break out the engine
> data into tables later if we decide it's a good idea.

Surely sounds good.

>   - db appears to have industrial strength locking, transactions, and
> logging with full recoverability if requested.

The recent comments suggesting replacement of the PostgreSQL underlying
storage engine with this implies that this provides an _appallingly_ 
potent engine to this purpose.

>   - db has dump and load to/from text format file routines, so people
> interested in a accessing their data in a text format will have a
> well documented method.

This will be a very popular aspect to it.

>   - db supports hot backups using normal unix tools.  You can just
> tar/cp/whatever your file while its open with no ill effects as
> long as the app properly uses the built in transaction mechanism.

I hadn't been aware of this; a Rather Attractive Feature for would-be
High Availability apps...

> Also, though this probably belongs as a separate discussion, and I
> haven't thought heavily about it yet, what about actually using it as
> our engine data storage format (i.e. splits as a subtable,
> transactions as a subtable, accounts as a subtable, etc.)?  It's not
> as sophisticated as SQL (though that's possibly a plus as much as a
> minus) since it's only a one dimensional hash, but you can build
> anything you want on top of that, and, as compared to our current
> approach, it seems like it might be better across the board.
> Of course, this question is orthogonal to whether or not it's the
> right thing to use to implement the "sectional data store" for
> non-engine data.

I rather like it as an approach.

> The nice thing is that if we do decide for now to just use it for our
> non-engine data (where the engine data is just a binary "blob" stored
> as one of the subnames in the database file), it should be a very
> straightforward step to break out the engine data into sub-tables
> later if that turns out to be a good idea.
> 
> Thoughts?
> 
> (Bracing for a long thread...)

I _rather_ like the idea of being able to use db_dump, which, I would
point out, comes as a standard part of the libdb2 distribution, to
serialize the DB out in text form. 

The fact that it provides reasonably full transactional support is a
goodly bonus.
--
Out of my mind. Back in five minutes. 
[EMAIL PROTECTED] - 

Re: gnucash 1.3.7 bugs.

[Jon A. Christopher]

To my understanding, that's only true if you're using a double-entry
ledger system.  The statements I get from my bank, and from every credit
card I've ever had use a debit to mean a charge...money going out of the
account, and a credit for money flowing into an account.  Thus the
terminology "deposits and other credits", and "checks and other debits".
I'm not an accountant, but I expect that the terms are still backwards.

-Jon

On Mon, 15 May 2000, Dave Peticolas wrote:

> 
> > 
> > I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> > 6.2 system.  The Account reconcile window has the credits and debits
> > columns reversed.
> > 
> > -Jon
> 
> Hi Jon, here is what happened. We recently discovered that we have
> been using the terms 'debit' and 'credit' incorrectly in GnuCash.
> In standard accounting practice, a debit is an increase in assets,
> such as a deposit to a bank account, and a credit is a decrease in
> assets, such as a payment, credit card charge, etc.
> 
> Starting in 1.3.7, we began using the terms according to the sense
> above, thus the change in column position of items in the reconcile
> window. I apologize for any confusion.
> 
> thanks,
> dave
> 

-- 
Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon

Re: gnucash 1.3.7 bugs.

[Richard Wackerbarth]

On Mon, 15 May 2000, Jon A. Christopher wrote:
> To my understanding, that's only true if you're using a double-entry
> ledger system.  The statements I get from my bank, and from every credit
> card I've ever had use a debit to mean a charge...money going out of the
> account, and a credit for money flowing into an account.  Thus the
> terminology "deposits and other credits", and "checks and other debits".
> I'm not an accountant, but I expect that the terms are still backwards.

The "problem" with credits/debits and bank statements is that it all depends 
whose books they are.

When you deposit some money at the bank, you think of it as an asset. The 
bank thinks of it as a liability (they have to pay it back).

Since most individuals don't keep books, they usually think of things 
reversed because they think that the statement is theirs when it is actually 
the banks.

Re: gnucash 1.3.7 bugs.

[Dave Peticolas]

> To my understanding, that's only true if you're using a double-entry
> ledger system.  The statements I get from my bank, and from every credit
> card I've ever had use a debit to mean a charge...money going out of the
> account, and a credit for money flowing into an account.  Thus the
> terminology "deposits and other credits", and "checks and other debits".
> I'm not an accountant, but I expect that the terms are still backwards.
 
Surprise, you are using a double-entry ledger system :) That is, unless
you are leaving all of your 'transfer from' fields blanks, all of your
entries in checking account have a matching entry in an expense, income,
etc. account.

I suppose we could make the meaning of 'debit' and 'credit' configurable.
It's really unfortunate that the informal meanings of the terms are exactly
opposite the accouting meanings.

dave

Re: gnucash 1.3.7 bugs.

[Christopher Browne]

On Mon, 15 May 2000 22:43:51 CDT, the world broke into rejoicing as
"Jon A. Christopher" <[EMAIL PROTECTED]>  said:
> To my understanding, that's only true if you're using a double-entry
> ledger system.  The statements I get from my bank, and from every credit
> card I've ever had use a debit to mean a charge...money going out of the
> account, and a credit for money flowing into an account.  Thus the
> terminology "deposits and other credits", and "checks and other debits".
> I'm not an accountant, but I expect that the terms are still backwards.

What is happening here is that the bank is reporting things from _THEIR_
perspective.

For them, a "debit memo" puts money in _THEIR_ account, and represents 
an income to THEM.

Which is mathematically opposite to what it is to you.

When you set up an account, and put $5000 in it, that may be "positive"
to you, something that you own.  From the bank's perspective, THEY OWE YOU
A DEBT.  Again, that's a symmetry whereby something that accounts _to_ you
accounts _against_ them.  Your perspective is, again, opposite to theirs.
--
Windows 'XCV -  A 32 bit patch for  a 16 bit interface to an  8 bit OS
designed for a 4 bit chip from  a 2 bit company that can't stand 1 bit
of competition...
[EMAIL PROTECTED] - 

Terminology

[Christopher Browne]

On Mon, 15 May 2000 21:24:58 PDT, the world broke into rejoicing as
Dave Peticolas <[EMAIL PROTECTED]>  said:
> > To my understanding, that's only true if you're using a double-entry
> > ledger system.  The statements I get from my bank, and from every credit
> > card I've ever had use a debit to mean a charge...money going out of the
> > account, and a credit for money flowing into an account.  Thus the
> > terminology "deposits and other credits", and "checks and other debits".
> > I'm not an accountant, but I expect that the terms are still backwards.
>  
> Surprise, you are using a double-entry ledger system :) That is, unless
> you are leaving all of your 'transfer from' fields blanks, all of your
> entries in checking account have a matching entry in an expense, income,
> etc. account.
> 
> I suppose we could make the meaning of 'debit' and 'credit' configurable.
> It's really unfortunate that the informal meanings of the terms are exactly
> opposite the accouting meanings.

Blame the evil bankers.  

They report things from their perspective that is exactly opposite
to yours.
--
Rules of the Evil Overlord #11. "I will be secure in my
superiority. Therefore, I will feel no need to prove it by leaving
clues in the form of riddles or leaving my weaker enemies alive to
show they pose no threat."  
[EMAIL PROTECTED] - 

Re: gnucash 1.3.7 bugs.

[Jon A. Christopher]

On Mon, 15 May 2000, Dave Peticolas wrote:

> > To my understanding, that's only true if you're using a double-entry
> > ledger system.  The statements I get from my bank, and from every credit
> > card I've ever had use a debit to mean a charge...money going out of the
> > account, and a credit for money flowing into an account.  Thus the
> > terminology "deposits and other credits", and "checks and other debits".
> > I'm not an accountant, but I expect that the terms are still backwards.
>  
> Surprise, you are using a double-entry ledger system :) That is, unless
> you are leaving all of your 'transfer from' fields blanks, all of your
> entries in checking account have a matching entry in an expense, income,
> etc. account.
> 
> I suppose we could make the meaning of 'debit' and 'credit' configurable.
> It's really unfortunate that the informal meanings of the terms are exactly
> opposite the accouting meanings.
> 
> dave

I'm not using gnucash's double-entry features.  Perhaps that'd be the best
solution---if using single-entry, use the informal meanings of
credit/debit, and if you're doing double entry, use the formal ones.  Or
just punt and call the columns "funds in" and "funds out" ;)

-Jon


-- 
Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon

Re: Use of Sleepycat DB

[Rob Walker]

> On Mon, 15 May 2000 22:45:16 -0500, Christopher Browne
> <[EMAIL PROTECTED]> said:

Christopher> On 15 May 2000 22:10:21 CDT, the world broke into rejoicing as
Christopher> Rob Browning <[EMAIL PROTECTED]>  said:

>> However, after poking around in the db docs (from now on, when I
>> say db here, I mean the sleepycat db), I'm wondering if this might
>> be much better candidate for that job than "rolling our own" fs
>> subtree approach.  For now, I'm putting aside the question of
>> whether or not we might want to break out the current engine data
>> as db tables.  For now I'm just interested in considering if using
>> db might be the best way to give us the "sectional data store".

Christopher> Lots of "food for thought."

okay, I will be the curmudgeon (sp?), here

"
   
  Berkeley DB is Open Source.  It's free for use in other Open Source
  projects, like PostgreSQL.  If a developer wants to use it in a
  proprietary application, then the developer needs to pay Sleepycat a
  licensing fee -- that's how we make our living.  But Open Source
  projects don't have to pay us anything.  You can download the full
  package from our Web site at www.sleepycat.com. 

"


doesn't sound too GPL to me.  Does this pose a problem with the
GPL'ness of gnucash?

rob

Re: gnucash 1.3.7 bugs.

[Rob Walker]

> On Tue, 16 May 2000 00:31:06 -0500 (CDT), "Jon A. Christopher"
> <[EMAIL PROTECTED]> said:

Jon> I'm not using gnucash's double-entry features.  Perhaps that'd be
Jon> the best solution---if using single-entry, use the informal
Jon> meanings of credit/debit, and if you're doing double entry, use
Jon> the formal ones.  Or just punt and call the columns "funds in"
Jon> and "funds out" ;)

Jon,

I am with you.  Confused when getting into using the double entry for
personal finances.  However, I am going to go ahead and do double
entry anyway, as it will be the best over the long run.

rob

Re: gnucash 1.3.7 bugs.

[Dave Peticolas]

> On Mon, 15 May 2000, Dave Peticolas wrote:
> 
> > > To my understanding, that's only true if you're using a double-entry
> > > ledger system.  The statements I get from my bank, and from every credit
> > > card I've ever had use a debit to mean a charge...money going out of the
> > > account, and a credit for money flowing into an account.  Thus the
> > > terminology "deposits and other credits", and "checks and other debits".
> > > I'm not an accountant, but I expect that the terms are still backwards.
> >  
> > Surprise, you are using a double-entry ledger system :) That is, unless
> > you are leaving all of your 'transfer from' fields blanks, all of your
> > entries in checking account have a matching entry in an expense, income,
> > etc. account.
> > 
> > I suppose we could make the meaning of 'debit' and 'credit' configurable.
> > It's really unfortunate that the informal meanings of the terms are exactly
> > opposite the accouting meanings.
> > 
> > dave
> 
> I'm not using gnucash's double-entry features.  Perhaps that'd be the best
> solution---if using single-entry, use the informal meanings of
> credit/debit, and if you're doing double entry, use the formal ones.  Or
> just punt and call the columns "funds in" and "funds out" ;)

I think the latter option is probably best, since making it possible
to reverse the meanings could end up being very confusing. Right now,
as long as you don't have 'always use debit/credit' labels in the
register, you only see debit/credit in:

+ asset, liability, and equity accounts
+ reconcile window
+ a few reports, though I just noticed their use of debit/credit
  needs to be fixed.

Most people not using double-entry are unlikely to use the
asset, etc. account types.

How about, as a first step, we make the reconcile window be
configurable to use, e.g., 'Funds In' and 'Funds Out' instead
of debit/credit as you suggest?

dave

Re: linking errors

[Christopher Browne]

On Mon, 15 May 2000 09:21:23 +0200, the world broke into rejoicing as
"T.Pospisek's MailLists" <[EMAIL PROTECTED]>  said:
> This is btw. with Robert's Debian g-wrap package, so the error -might-
> also be there.
> 
> Has anybody else seen this?
> *t
> 
> ../../src/engine/obj/Session.o: In function `xaccSessionBeginSQL':
> /home/tpo/ftp/gnucash/cvs/gnucash/src/engine/Session.c:200: undefined
> reference to `pgendNew'
> /home/tpo/ftp/gnucash/cvs/gnucash/src/engine/Session.c:209: undefined
> reference to `xaccGroupSetBackend'
> ../../src/engine/obj/Transaction.o: In function `xaccTransCommitEdit':
> /home/tpo/ftp/gnucash/cvs/gnucash/src/engine/Transaction.c:1066: undefined
> reference to `xaccTransactionGetBackend'
> collect2: ld returned 1 exit status

That sure looks like a set of calls that relate somehow to the use of
PostgreSQL.

Could you have done some hacking on the beginnings of an SQL backend?
Or could someone else have checked such in?
--
When your hammer is C++, everything begins to look like a thumb.
-- Steve Hoflich on comp.lang.c++
[EMAIL PROTECTED] -