Having said that, we shouldn't rule out users accessing the data
out from under GnuCash, at least in a read-only means. I still
believe that external tools should not be writing data into the
GnuCash database.
Have you thought about how allow other applications could use GnuCash engine
to
Quoting Daniel Espinosa [EMAIL PROTECTED]:
Having said that, we shouldn't rule out users accessing the data
out from under GnuCash, at least in a read-only means. I still
believe that external tools should not be writing data into the
GnuCash database.
Have you thought about how allow
On November 20, 2008 11:27:03 pm Daniel Espinosa wrote:
If you look at libqof's code you'll find that all GC's QOF implementation
is based in store *all* data object in memory using a GHashTable using a
string for the object type and GUID for identification, any search for any
object is a
On November 20, 2008 06:38:14 pm Phil Longstaff wrote:
On November 16, 2008 02:01:05 pm Derek Atkins wrote:
Phil Longstaff [EMAIL PROTECTED] writes:
Wait, the ENTIRE contents are read in? Historically only necessary
data was read in. That would be the Accounts and Commodities from
On November 16, 2008 02:01:05 pm Derek Atkins wrote:
Phil Longstaff [EMAIL PROTECTED] writes:
Wait, the ENTIRE contents are read in? Historically only necessary
data was read in. That would be the Accounts and Commodities from
the main CoA. The transactions were all loaded on demand.
If you look at libqof's code you'll find that all GC's QOF implementation is
based in store *all* data object in memory using a GHashTable using a string
for the object type and GUID for identification, any search for any object
is a foreach routine.
This implementation is good for XML data
Marcus Wolschon [EMAIL PROTECTED] writes:
2008/11/18 Derek Atkins [EMAIL PROTECTED]:
Marcus Wolschon [EMAIL PROTECTED] writes:
Or using stored procedures to create transactions
uppon changes being made in other databases
on the same DBMS (like a webshop-database).
We cannot depend on
Derek Atkins wrote:
If you're loading all data all the time then the only benefit to the DB
backend over the XML backend is save-on-commit.
For me, the biggest benefit is accessability of the data. XML query
tools don't match their SQL counterparts even remotely. I'd go as far
as saying that
2008/11/18 Rolf Leggewie [EMAIL PROTECTED]:
Derek Atkins wrote:
If you're loading all data all the time then the only benefit to the DB
backend over the XML backend is save-on-commit.
For me, the biggest benefit is accessability of the data. XML query
tools don't match their SQL
Rolf Leggewie wrote:
While it will complicate things
a little bit, I may probably use the guid space as key which is
inherently larger than the code space.
Not only does it complicate things quite a bit (I have yet to find a
tool that allows to link SQL tables and update the data in them -
Marcus Wolschon [EMAIL PROTECTED] writes:
Or using stored procedures to create transactions
uppon changes being made in other databases
on the same DBMS (like a webshop-database).
We cannot depend on Stored Procedures because not all the supported
DBs support them.
Please remember to CC
Rolf Leggewie [EMAIL PROTECTED] writes:
One potentially VERY huge advantage of the SQL backend that I forgot is
of course simultaneous access by more than one user.
Multi-user access is not a goal in the first release, but it is certainly
something that would be nice to add. And yes, a SQL
Derek Atkins wrote:
Multi-user access is not a goal in the first release, but it is certainly
something that would be nice to add. And yes, a SQL Backend is necessary
but not sufficient for multi-user.
Not addressing the multi user issue now will cause a significant number
of bugs to be
2008/11/18 Derek Atkins [EMAIL PROTECTED]:
Marcus Wolschon [EMAIL PROTECTED] writes:
Or using stored procedures to create transactions
uppon changes being made in other databases
on the same DBMS (like a webshop-database).
We cannot depend on Stored Procedures because not all the supported
On November 16, 2008 02:01:05 pm Derek Atkins wrote:
Phil Longstaff [EMAIL PROTECTED] writes:
Wait, the ENTIRE contents are read in? Historically only necessary
data was read in. That would be the Accounts and Commodities from
the main CoA. The transactions were all loaded on demand.
Ian Smith-Heisters wrote:
On Wed, Nov 12, 2008 at 6:11 PM, Derek Atkins [EMAIL PROTECTED] wrote:
Hi,
Quoting Eric Anopolsky [EMAIL PROTECTED]:
I'm not familiar with gnucash's data structures so I'm not 100% sure
what a code is, but would it be possible to identify each account by
Phil Longstaff [EMAIL PROTECTED] writes:
Wait, the ENTIRE contents are read in? Historically only necessary
data was read in. That would be the Accounts and Commodities from
the main CoA. The transactions were all loaded on demand.
Yes. I wanted to only read necessary data. However, my
Phil,
Phil Longstaff [EMAIL PROTECTED] writes:
On November 13, 2008 10:10:53 am Derek Atkins wrote:
What exactly is the use-case for using codes as a primary key?
Keep in mind that the SQL Backend data store is just that, a
data store. GnuCash does NOT use database constraints, and
for
Hello everybody,
Herbert Thoma wrote:
What exactly is the use-case for using codes as a primary key?
I'm not following this list daily. I just joined this discussion which
also concerns me to a great extent.
Phil already gave a bit of explanation. I'll try to give my
perspective, too.
On November 14, 2008 08:30:11 am Derek Atkins wrote:
Phil,
I must have missed this, because I don't remember reading the original
request. I don't understand what additional table is required.
I'm trying to think about it from the GnuCash use standpoint, not
the backend storage aspect.
--- On Thu, 11/13/08, Derek Atkins [EMAIL PROTECTED] wrote:
From: Derek Atkins [EMAIL PROTECTED]
Subject: Re: String lengths in the SQL backend
To: [EMAIL PROTECTED]
Cc: Gnucash list [EMAIL PROTECTED], [EMAIL PROTECTED], Phil Longstaff
[EMAIL PROTECTED]
Date: Thursday, November 13, 2008
Derek Atkins wrote:
Uhh, yeah. Sorry. Totally unreasonable.
The code in question is a user-input field. Historically accountants
used codes instead of names to keep track of accounts. So GnuCash provides
a place for you to enter in an Account Code. But it's a string, not a number.
Phil Longstaff [EMAIL PROTECTED] schrieb am Wed, 12 Nov 2008
10:24:03 -0500:
Can anyone think of a reason that account code size limit cannot be
reduced to a smaller value (e.g. 32)? Will anyone ever enter an
account code longer than that?
I can't, but I'm sure sooner or later a user will
I agree that this would be the best course of action.
Use a separate key for the codes. Internally, link the tables using the keys,
and only where user interaction is expected, present the code.
My 2c.
Geert
On Thursday 13 November 2008, Graham Leggett wrote:
Derek Atkins wrote:
Uhh, yeah.
Herbert Thoma [EMAIL PROTECTED] writes:
Ah well, I have a 30, 2560 pixel wide screen, 256 chars on a single
line is possible, if the font is not too large ...
Rolf wants german SKR4 account codes and these are 6 or 8 digit numerical
codes, but that fact does not help since other users may
Paul Schwartz [EMAIL PROTECTED] writes:
I've worked with several accounting packages, and I would find it
very strange if someone could not adapt their procedures to live
with 32 for the length of the account code.
Except that the UI makes no limitation on the field size...
So people who
Roland Roberts [EMAIL PROTECTED] writes:
I confess I haven't been paying attention to the SQL backend in a
while. I'm one who would very much like to have this working since my
wife and I often run into conflicts having to serialize our data entry
(neither of us has much time to do data
On November 13, 2008 10:12:32 am Derek Atkins wrote:
Roland Roberts [EMAIL PROTECTED] writes:
I confess I haven't been paying attention to the SQL backend in a
while. I'm one who would very much like to have this working since my
wife and I often run into conflicts having to serialize our
Derek Atkins schrieb:
Herbert Thoma [EMAIL PROTECTED] writes:
Ah well, I have a 30, 2560 pixel wide screen, 256 chars on a single
line is possible, if the font is not too large ...
Rolf wants german SKR4 account codes and these are 6 or 8 digit numerical
codes, but that fact does not help
On November 13, 2008 10:10:53 am Derek Atkins wrote:
What exactly is the use-case for using codes as a primary key?
Keep in mind that the SQL Backend data store is just that, a
data store. GnuCash does NOT use database constraints, and
for Accounts it doesn't even need to use an Index,
.
I'd have to look back, but I think Derek's reply was the only one. I'd like
to open the topic again, because of Rolf's problem. Can anyone think of a
reason that account code size limit cannot be reduced to a smaller value (e.g.
32)? Will anyone ever enter an account code longer than
On Wed, Nov 12, 2008 at 10:24 AM, Phil Longstaff [EMAIL PROTECTED] wrote:
For those on the gnucash user list, a new SQL backend is in development. An
issue has arisen, and I need to get input from users, not just developers.
Rolf Leggewie has run into some problems with the SQL backend
: String lengths in the SQL backend
To: Gnucash list [EMAIL PROTECTED], [EMAIL PROTECTED]
Date: Wednesday, November 12, 2008, 8:24 AM
For those on the gnucash user list, a new SQL backend is in
development. An
issue has arisen, and I need to get input from users, not
just developers.
Rolf
Mike or Penny Novack schrieb:
.
I'd have to look back, but I think Derek's reply was the only one. I'd like
to open the topic again, because of Rolf's problem. Can anyone think of a
reason that account code size limit cannot be reduced to a smaller value
(e.g.
32)? Will anyone
On November 12, 2008 11:22:34 am Donald Allen wrote:
Why is mysql an issue? I thought the backend was going to be sqlite3?
Perhaps you are doing a generic sql layer, designed to talk any one of
many target databases, or the specific target database has changed?
It uses a library which
On November 12, 2008 12:11:13 pm Donald Allen wrote:
On Wed, Nov 12, 2008 at 11:48 AM, Phil Longstaff [EMAIL PROTECTED]
wrote:
On November 12, 2008 11:22:34 am Donald Allen wrote:
Why is mysql an issue? I thought the backend was going to be sqlite3?
Perhaps you are doing a generic sql
Phil Longstaff wrote:
I'd have to look back, but I think Derek's reply was the only one. I'd like
to open the topic again, because of Rolf's problem. Can anyone think of a
reason that account code size limit cannot be reduced to a smaller value (e.g.
32)? Will anyone ever enter an account
On Wed, Nov 12, 2008 at 11:48 AM, Phil Longstaff [EMAIL PROTECTED] wrote:
On November 12, 2008 11:22:34 am Donald Allen wrote:
Why is mysql an issue? I thought the backend was going to be sqlite3?
Perhaps you are doing a generic sql layer, designed to talk any one of
many target databases, or
Phil Longstaff wrote:
For those on the gnucash user list, a new SQL backend is in development. An
issue has arisen, and I need to get input from users, not just developers.
Rolf Leggewie has run into some problems with the SQL backend
(http://bugzilla.gnome.org/show_bug.cgi?id=560165) - he
On Wed, 2008-11-12 at 10:24 -0500, Phil Longstaff wrote:
For those on the gnucash user list, a new SQL backend is in development. An
issue has arisen, and I need to get input from users, not just developers.
Rolf Leggewie has run into some problems with the SQL backend
Hi,
Quoting Eric Anopolsky [EMAIL PROTECTED]:
I'm not familiar with gnucash's data structures so I'm not 100% sure
what a code is, but would it be possible to identify each account by
an int or a bigint instead of a code? Then this secondary table could
have the account int as its foreign
On Wed, Nov 12, 2008 at 6:11 PM, Derek Atkins [EMAIL PROTECTED] wrote:
Hi,
Quoting Eric Anopolsky [EMAIL PROTECTED]:
I'm not familiar with gnucash's data structures so I'm not 100% sure
what a code is, but would it be possible to identify each account by
an int or a bigint instead of a
Well, my 2ct here:
I am using the account-code to store item-numbers/item-barcodes (assets)
or account-numbers (bank-accounts). Item-numbers can get quite long
(think the serial-number identifying a laptop) but 32 characters should be okay,
as long as it's not 32 byte (think Unicode).
How far
43 matches
Mail list logo
