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 abo
>
> 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 engin
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 Commodit
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 f
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 store,
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 o
"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).
>>
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
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 repo
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
"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
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 ->
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 co
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
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 o
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".
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 id
--- 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 Longs
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 aspec
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.
Firs
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
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, bec
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
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 serial
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 d
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
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
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, yea
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 wi
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.
Grante
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 has
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 in
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 f
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
> (http://bugzill
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)
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 dat
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 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 generi
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 supp
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)? Wil
;[EMAIL PROTECTED]>
> Subject: 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
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
>
>.
>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
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 wants to add another
SQL
44 matches
Mail list logo
