Re: python GnuCash interface to SQL backend

Sébastien de Menten writes: > On Monday, November 17, 2014, Derek Atkins wrote: > > I think most of our beef against your project is that you're making it > read-write.  If it was read-only then nobody here would care. > > Yes indeed. Me first needs are a) to read a GnuCash boom from pyt

Re: python GnuCash interface to SQL backend

On Monday, November 17, 2014, Derek Atkins wrote: > > I think most of our beef against your project is that you're making it > read-write. If it was read-only then nobody here would care. > > Yes indeed. Me first needs are a) to read a GnuCash boom from python and b) to create some new objects (

Re: python GnuCash interface to SQL backend

Sébastien de Menten writes: > On Fri, Nov 14, 2014 at 3:33 AM, Derek Atkins wrote: > > John Ralls writes: > > > What’s your goal here? I don’t think that reimplementing GnuCash in > > Python with GnuCash’s SQL schema is a particularly good approach: It’s > > not exactly the

Re: python GnuCash interface to SQL backend

On Saturday, November 15, 2014, Christian Stimming wrote: > Dear Sébastien, > > I really try not to be rude, but a little bit it seems to me as if you > don't > accept "no" as an answer here. You asked whether the gnucash developers > support an alternative SQL access layer written in python from

Re: python GnuCash interface to SQL backend

Dear Sébastien, I really try not to be rude, but a little bit it seems to me as if you don't accept "no" as an answer here. You asked whether the gnucash developers support an alternative SQL access layer written in python from scratch, and John's and other answers clearly said "no". What else

Re: python GnuCash interface to SQL backend

> On Nov 15, 2014, at 7:08 AM, Sébastien de Menten wrote: > > Hello John, > > I have put at this address > https://github.com/sdementen/piecash/blob/master/docs/source/object_model.rst > > what I understood from

Re: python GnuCash interface to SQL backend

> On Nov 14, 2014, at 3:18 PM, Sébastien de Menten wrote: > > > > On Friday, November 14, 2014, John Ralls > wrote: > >> On Nov 14, 2014, at 4:28 AM, Sébastien de Menten > > wrote: >> >> >> In terms of the implementation itself of the object model, the main thing

Re: python GnuCash interface to SQL backend

Hello John, I have put at this address https://github.com/sdementen/piecash/blob/master/docs/source/object_model.rst what I understood from the object model of GnuCash (schema/fields/invariants). I have also added some questions regarding the objects for which you may have the answer... (or these

Re: python GnuCash interface to SQL backend

On Friday, November 14, 2014, John Ralls wrote: > > On Nov 14, 2014, at 4:28 AM, Sébastien de Menten > wrote: > > > In terms of the implementation itself of the object model, the main things > I see not that clean are: > - KVP vs field representation > - XXX_denom / XXX_num split (instead of usi

Re: python GnuCash interface to SQL backend

> On Nov 14, 2014, at 4:28 AM, Sébastien de Menten wrote: > > First of all, thank you John for taking the time to answer to this thread ! > > > > If you see GnuCash from the (limited) perspective of an editor for a Book > > document (as LibreOffice Writer is an editor for a ODT document), obj

Re: python GnuCash interface to SQL backend

; Moreover, you're also tied to a particular backend, which isn't very > nice. > > Indeed, piecash is only applicable to the SQL backend and depends on the version of the "SQL schema" used by GnuCash. But as GnuCash is rather good at keeping backward compatibility, my fears a

Re: python GnuCash interface to SQL backend

On Fri, Nov 14, 2014 at 3:33 AM, Derek Atkins wrote: > John Ralls writes: > > > What’s your goal here? I don’t think that reimplementing GnuCash in > > Python with GnuCash’s SQL schema is a particularly good approach: It’s > > not exactly the most efficient design. Rather, it’s designed to mirro

Re: python GnuCash interface to SQL backend

First of all, thank you John for taking the time to answer to this thread ! > > If you see GnuCash from the (limited) perspective of an editor for a > Book document (as LibreOffice Writer is an editor for a ODT document), > object persistence is central. And luckily we have both a very clean and

Re: python GnuCash interface to SQL backend

John Ralls writes: > What’s your goal here? I don’t think that reimplementing GnuCash in > Python with GnuCash’s SQL schema is a particularly good approach: It’s > not exactly the most efficient design. Rather, it’s designed to mirror > the XML schema. You’ll have a better design if you relegate

Re: python GnuCash interface to SQL backend

Sébastien de Menten writes: > Where could I find detailed documentation on the GnuCash engine (and the > constrains/invariants GnuCash enforces) ? Or would there be some > code/program to check a GnuCash file is "sane/consistent" ? Only in the implementation. There is no documentation per se on

Re: python GnuCash interface to SQL backend

On Nov 13, 2014, at 12:44 PM, Sébastien de Menten wrote: > > On 2014-11-13 19:25, John Ralls wrote: >> On Nov 13, 2014, at 9:31 AM, Sébastien de Menten wrote: >> >>> Indeed, it may be worth to explain what are the goals (and the limits). >>> >>> I have tried to use the official python bindin

Re: python GnuCash interface to SQL backend

On 2014-11-13 19:25, John Ralls wrote: On Nov 13, 2014, at 9:31 AM, Sébastien de Menten wrote: Indeed, it may be worth to explain what are the goals (and the limits). I have tried to use the official python bindings and had the following issues: - need swig + compilations to make them work =

Re: python GnuCash interface to SQL backend

in Scheme. >>> >>> It may also be easier to go with the SQL than with the std python binding >>> for reporting but also to change the GnuCash book. >> >> It might be, but I doubt it. You won’t be able to implement the business >> logic in SQL alone. >>

Re: python GnuCash interface to SQL backend

ness logic is in the python code. For > instance, when creating a transaction and the related splits, it is the > python code that ensures the business logic (for instance that the sum of the > splits = 0). This is close to what GnuCash does. > Moreover, there are some basic SQL

Re: python GnuCash interface to SQL backend

gic (for instance that the sum of the splits = 0). This is close to what GnuCash does. Moreover, there are some basic SQL integrity constrains (we cannot remove a split without removing the related transaction) that are added in the ORM layer as they do not exist in the SQL backend. > > >

Re: python GnuCash interface to SQL backend

k prices. I had the impression that GnuCash does indeed calculations when the book is opened but that it does not save them in the SQL backend. Hence, if we access the book when it's not opened by GnuCash at the same time, risks are quite reduced, would this be a "wrong" impression ?

Re: python GnuCash interface to SQL backend

; John Ralls > > > > I have mainly used the basic objects from GnuCash required for basic personal > finance (so no invoice, no budget, ...) and did not found any issues while > handling lot of accounts/transactions/splits and stock prices. I had the > impression that GnuCash

Re: python GnuCash interface to SQL backend

> On Nov 11, 2014, at 1:10 PM, Sébastien de Menten wrote: > > Hello, > > After trying multiple times to work with GnuCash from python (via xml, via > the python bindings, via sql), I finally had a try to use SQLAlchemy to > handle the GnuCash Books saved through the SQL

python GnuCash interface to SQL backend

Hello, After trying multiple times to work with GnuCash from python (via xml, via the python bindings, via sql), I finally had a try to use SQLAlchemy to handle the GnuCash Books saved through the SQL backend (sqlite3 and postgres). I have a release on PyPI the package "pyscash" i

Re: SQL backend: Where do we store the password?

On 02-07-13 20:53, Christian Stimming wrote: Dear Geert or John or whoever knows this, where does gnucash store the database password for MySQL or PostgreSQL backend? It stores the database name, host, and username directly in the URI, which is also visible in the file history. The URI (without

SQL backend: Where do we store the password?

Dear Geert or John or whoever knows this, where does gnucash store the database password for MySQL or PostgreSQL backend? It stores the database name, host, and username directly in the URI, which is also visible in the file history. The URI (without the password) is also stored in gconf and ca

RE: Creating new customer with Python bindings and SQL backend

09:21 To: gnucash-devel@gnucash.org Subject: Creating new customer with Python bindings and SQL backend -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello guys, I am trying to create a new customer using the Python bindings. I am using an SQL backend (PostgreSQL). I follow the examples and do

Creating new customer with Python bindings and SQL backend

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello guys, I am trying to create a new customer using the Python bindings. I am using an SQL backend (PostgreSQL). I follow the examples and do new_customer = Customer(book, '0', USD, 'foo bar') Of course, the currency USD

Re: [Bug 632166] sql backend silently fails and loses data

sting because 2.3.15's doesn't -- so that's a regression that needs to be fixed on top of everything else. On the other hand, I'm leaning towards making the sql backend just note the missing currency in the log. That seems to be what the xml backend does. Even bette

Re: [Bug 632166] sql backend silently fails and loses data

John -- This is reminiscent of a bug, 609583, that I reported and you and I worked on earlier this year. I just wanted to remind you of it in case the issues are the same (I haven't read the two bug reports carefully) and, if so, there might be something of use to you in the older report.. /Don

Re: [Bug 632166] sql backend silently fails and loses data

For a bug as grave as this one it is completely ok to break the string freeze. You can just go ahead and commit. Thanks! Christian Zitat von John Ralls : I've been working on https://bugzilla.gnome.org/show_bug.cgi?id=632166 this afternoon. I can reproduce the bug, and I've added (but no

[Bug 632166] sql backend silently fails and loses data

I've been working on https://bugzilla.gnome.org/show_bug.cgi?id=632166 this afternoon. I can reproduce the bug, and I've added (but not yet checked in) a log message with more detail than the g_return_val_if_fail message. There should probably be one for each failure reason. But to really addre

Re: We need to prevent multi-user access to the SQL backend - What about Python access ?

Christoph Holtermann writes: > Hello ! > > I guess a python-script using the python-bindings which accesses the > SQL-Database would be the same as another user accessing it ? Yes. > Gnucash and my script coexist peacefully but i decided to not run them > the same time for i feared data destru

Re: We need to prevent multi-user access to the SQL backend - What about Python access ?

Hello ! I guess a python-script using the python-bindings which accesses the SQL-Database would be the same as another user accessing it ? Gnucash and my script coexist peacefully but i decided to not run them the same time for i feared data destruction. It would be nice, though. bye, C. Holte

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

On 21 May 2010, at 6:04 PM, Derek Atkins wrote: Because a situation arises when both of you need to make writes. Which copy is the authoritative copy? Using svn alleviates this somewhat, but isn't ideal. The authoritative copy belongs to whomever has the "write token". Otherwise known as t

Re: We need to prevent multi-user access to the SQL backend

On Fri, May 21, 2010 at 4:29 PM, Colin Law wrote: > On 20 May 2010 19:48, Gour wrote: >> On Thu, 20 May 2010 12:55:01 -0400 "Derek" == Derek Atkins wrote: >> >> Derek> IMNSHO, adding MySQL and PG support was a mistake; we should >> Derek> have stuck with just SQLite. >> >> +1 > > -1, I

Re: We need to prevent multi-user access to the SQL backend

On 20 May 2010 19:48, Gour wrote: > On Thu, 20 May 2010 12:55:01 -0400 >>> "Derek" == Derek Atkins wrote: > > Derek> IMNSHO, adding MySQL and PG support was a mistake; we should > Derek> have stuck with just SQLite. > > +1 -1, I am very grateful for MySQL. I am generating web based reports

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

Graham Leggett writes: >> Why not? > > Because a situation arises when both of you need to make writes. Which > copy is the authoritative copy? Using svn alleviates this somewhat, > but isn't ideal. The authoritative copy belongs to whomever has the "write token". > It is really easy to silentl

Re: We need to prevent multi-user access to the SQL backend

On Thu, 20 May 2010 12:55:01 -0400 >> "Derek" == Derek Atkins wrote: Derek> IMNSHO, adding MySQL and PG support was a mistake; we should Derek> have stuck with just SQLite. +1 Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

On 20 May 2010, at 6:55 PM, Derek Atkins wrote: Well, over time one would hope that we can slowly rearchitect gnucash to be more aware of multi-user situations. I'm keen to do some of that work, as I need it directly. In any practical usage, even in it's simplest form, you start off small

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

Graham Leggett writes: > On 20 May 2010, at 6:32 PM, Derek Atkins wrote: > Your solution to block the whole database is good enough for me. >>> >>> It's a real shame that a system fundamentally designed to offer multi >>> user access to data should be crippled in such a fashion. In the >>> p

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

On 20 May 2010, at 6:32 PM, Derek Atkins wrote: Your solution to block the whole database is good enough for me. It's a real shame that a system fundamentally designed to offer multi user access to data should be crippled in such a fashion. In the process, virtually all reasons to use a SQL da

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

Valdis Vītoliņš writes: > I vote for not over-engineered solution and, I suppose simple lock for > all database (only one can write) is OK. > > My clients/partners will not use SQL backend. They use Gnucash because > it can be installed and used as many other standalone applic

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

Graham Leggett writes: > On 19 May 2010, at 11:47 PM, Per Kjeldaas wrote: > >> Your solution to block the whole database is good enough for me. > > It's a real shame that a system fundamentally designed to offer multi > user access to data should be crippled in such a fashion. In the > process, v

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

gt; The article raises one valid serious concern: The database backend does >> nothing to prevent multiple user access. This is bad because simultaneous >> access to the SQL database from multiple users will almost surely cause data >> loss. On the other hand, the technology term "SQ

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

On 19 May 2010, at 11:47 PM, Per Kjeldaas wrote: Your solution to block the whole database is good enough for me. It's a real shame that a system fundamentally designed to offer multi user access to data should be crippled in such a fashion. In the process, virtually all reasons to use a S

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

t; nothing to prevent multiple user access. This is bad because simultaneous >> access to the SQL database from multiple users will almost surely cause data >> loss. On the other hand, the technology term "SQL backend" will almost >> surely raise the user expectation that m

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

I vote for not over-engineered solution and, I suppose simple lock for all database (only one can write) is OK. My clients/partners will not use SQL backend. They use Gnucash because it can be installed and used as many other standalone applications. It is important, that Gnucash save data in

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

data > loss. On the other hand, the technology term "SQL backend" will almost > surely raise the user expectation that multiple user access were possible, > so for sure people will give it a try. Since it will corrupt their data, we > need to build in some prevention measure -

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

iple user access. This is bad because simultaneous >> access to the SQL database from multiple users will almost surely cause data >> loss. On the other hand, the technology term "SQL backend" will almost >> surely raise the user expectation that multiple user access were p

Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

> Thanks, Herbert, for the link. > > The article raises one valid serious concern: The database backend does > nothing to prevent multiple user access. This is bad because simultaneous > access to the SQL database from multiple users will almost surely cause data > loss. On the other ha

We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)

technology term "SQL backend" will almost surely raise the user expectation that multiple user access were possible, so for sure people will give it a try. Since it will corrupt their data, we need to build in some prevention measure - the equivalent of the "lock file",

Re: problems with sql-backend

Rolf Leggewie writes: > Phil Longstaff wrote: >>> After the update to r18792, one of my sqlite3-based gnucash files > >> which was fixed in r18805. You should update to at least 18855 > >> If that doesn't fix your problem, let me know. > > I first noticed the problem with r18792 which is past th

Re: problems with sql-backend

Phil Longstaff wrote: >> After the update to r18792, one of my sqlite3-based gnucash files > which was fixed in r18805. You should update to at least 18855 > If that doesn't fix your problem, let me know. I first noticed the problem with r18792 which is past the revisions you mentioned. ___

Re: problems with sql-backend

On Sat, 2010-03-20 at 17:28 +0100, Rolf Leggewie wrote: > Phil Longstaff wrote: > >> After the update to r18792, one of my sqlite3-based gnucash files > > > which was fixed in r18805. You should update to at least 18855 > > > If that doesn't fix your problem, let me know. > > I first noticed th

Re: problems with sql-backend

On Fri, 2010-03-19 at 01:29 +0100, Rolf Leggewie wrote: > Hi, > > I've been using the sql-backend for quite some time. I've been > compiling my deb packages from svn to do that. I recently upgraded my > machine from lucid to karmic and cooked up a new svn snapshot at

problems with sql-backend

Hi, I've been using the sql-backend for quite some time. I've been compiling my deb packages from svn to do that. I recently upgraded my machine from lucid to karmic and cooked up a new svn snapshot at about the same time. I believe I had previously been running r18249 for qui

Re: SQL backend performance

Donald Allen writes: > Some good news: > > Doing this the easy way first, I did a little manual pc sampling. I > ran gnucash (today's trunk) under gdb, let it get to the point where > it begins to load my data from postgresql, and periodically ctrl-c'd > in gdb and copied the interrupted location

Re: Code formatting Re: SQL backend performance

On Thu, 2010-02-25 at 09:49 +0100, Christian Stimming wrote: > Zitat von Phil Longstaff : > >> http://lists.gnucash.org/pipermail/gnucash-devel/2009-August/026121.html > >> and > >> my commit r18675 recently. I didn't apply this to the full source > >> tree so far > >> in order not to destroy so

Re: Code formatting Re: SQL backend performance

Zitat von Phil Longstaff : http://lists.gnucash.org/pipermail/gnucash-devel/2009-August/026121.html and my commit r18675 recently. I didn't apply this to the full source tree so far in order not to destroy some people's diffs which are still waiting to be applied... I think the directory you'r

Re: Code formatting Re: SQL backend performance

On Wed, 2010-02-24 at 22:18 +0100, Geert Janssens wrote: > On Wednesday 24 February 2010, Phil Longstaff wrote: > > On Wed, 2010-02-24 at 20:50 +0100, Christian Stimming wrote: > > Christian, could you create such a central file with the options you are > > using? > > > Agreed on the idea of an op

Re: Code formatting Re: SQL backend performance

On Wednesday 24 February 2010, Phil Longstaff wrote: > On Wed, 2010-02-24 at 20:50 +0100, Christian Stimming wrote: > > > So I applied the same treatment to load_splits_for_tx_list, > > > substituting g_list_prepend for g_list_append inside the > > > split-fetching loop and reversing the list on co

Code formatting Re: SQL backend performance

On Wed, 2010-02-24 at 20:50 +0100, Christian Stimming wrote: > > So I applied the same treatment to load_splits_for_tx_list, > > substituting g_list_prepend for g_list_append inside the > > split-fetching loop and reversing the list on completion of the loop. > > I rebuilt and tried again and now m

Re: Scheme formatting with astyle [Was: SQL backend performance]

On Wed, Feb 24, 2010 at 12:09 PM, Jeff Kletsky wrote: > On 2/24/2010 11:50 AM, Christian Stimming wrote: > >> As for the patch and indentation: Indeed we discussed and agreed on some >> common indentation last summer, and we agreed on using the tool astyle to >> reformat the code as decided. See

Re: SQL backend performance

On Wed, 2010-02-24 at 14:37 -0500, Donald Allen wrote: Great! I'll apply the patch. There are probable other places which would benefit from this. There might also be places where the order is unimportant so that the list doesn't need to be reversed. > BTW, I found the indentation/formatting o

Scheme formatting with astyle [Was: SQL backend performance]

On 2/24/2010 11:50 AM, Christian Stimming wrote: As for the patch and indentation: Indeed we discussed and agreed on some common indentation last summer, and we agreed on using the tool astyle to reformat the code as decided. See http://lists.gnucash.org/pipermail/gnucash-devel/2009-August/026121

Re: SQL backend performance

> So I applied the same treatment to load_splits_for_tx_list, > substituting g_list_prepend for g_list_append inside the > split-fetching loop and reversing the list on completion of the loop. > I rebuilt and tried again and now my data loads in about 9 seconds, > approximately the same as the xml

Re: SQL backend performance

Some good news: Doing this the easy way first, I did a little manual pc sampling. I ran gnucash (today's trunk) under gdb, let it get to the point where it begins to load my data from postgresql, and periodically ctrl-c'd in gdb and copied the interrupted location and a backtrace to an emacs buffe

Re: SQL backend performance

On Wed, Feb 24, 2010 at 10:32 AM, Phil Longstaff wrote: > On Wed, 2010-02-24 at 09:59 -0500, Derek Atkins wrote: >> Donald Allen writes: >> >> >> I think true measurements will be the only way to find out what causes >> >> delays >> >> where. >> > >> > Of course. I spent a big chunk of my career

Re: SQL backend performance

On Wed, 2010-02-24 at 09:59 -0500, Derek Atkins wrote: > Donald Allen writes: > > >> I think true measurements will be the only way to find out what causes > >> delays > >> where. > > > > Of course. I spent a big chunk of my career doing performance analysis > > on various bits of complicated so

Re: SQL backend performance

Donald Allen writes: >> I think true measurements will be the only way to find out what causes delays >> where. > > Of course. I spent a big chunk of my career doing performance analysis > on various bits of complicated software and learned very young (the > hard way) that if you think you know h

Re: SQL backend performance

ease as well. >> > >> > There is one difference between the xml and the sql backends that may >> > influence this (at least in part): the sql backend writes lots of debug >> > information to gnucash.trace at present. I don't know how much impact >> >

Re: SQL backend performance

xml and the sql backends that may > > influence this (at least in part): the sql backend writes lots of debug > > information to gnucash.trace at present. I don't know how much impact > > this has, I haven't tested without debug information, but if we disable > > the debug in

Re: SQL backend performance

On Tue, Feb 23, 2010 at 9:15 AM, Geert Janssens wrote: > On Tuesday 23 February 2010, Donald Allen wrote: >> As I've mentioned in other posts, I have a pretty large gnucash >> datafile -- more than 20 Mb uncompressed. I've been testing the SQL >> backend and I&#x

Re: SQL backend performance

On Tuesday 23 February 2010, Donald Allen wrote: > As I've mentioned in other posts, I have a pretty large gnucash > datafile -- more than 20 Mb uncompressed. I've been testing the SQL > backend and I'm concerned about the performance, particularly startup > performance

SQL backend performance

As I've mentioned in other posts, I have a pretty large gnucash datafile -- more than 20 Mb uncompressed. I've been testing the SQL backend and I'm concerned about the performance, particularly startup performance. I've been doing this testing on an inexpensive little HP d

Re: Re: Another problem with scheme query and SQL backend (Phil Longstaff)

Am Samstag, den 20.06.2009, 12:00 -0400 schrieb gnucash-devel-requ...@gnucash.org: > Message: 1 > Date: Fri, 19 Jun 2009 12:52:37 -0400 > From: Phil Longstaff > Subject: Re: Another problem with scheme query and SQL backend > To: gnucash-devel@gnucash.org > Message-ID: &

Re: Another problem with scheme query and SQL backend

On May 31, 2009 12:41:13 pm Phil Longstaff wrote: > On May 31, 2009 06:53:23 am Erwin Rieger wrote: > > Hi, > > > > i have another funny problem with querying data from scheme with the > > (my)sql backend. > > > > The query from my previous posts do only retu

Re: How to integrate with new SQL backend

Hi, Quoting "Pelton, Brian" : [snip] My first question is - is it insane to want to have one data source? Not insane, but not necessarily a good idea.. Depends how the data is to be shared. Are the risks of messing something up are too great, so leave it as is? IMNSHO, yes. Second ques

How to integrate with new SQL backend

Seeking advice and opinions ... I have an application that I wrote that reads the GnuCash XML file and exports that data into an SQLite database. From there, it performs budgeting and reporting stuff against the SQLite database. So, now that GnuCash has an SQLite backend, I'm thinking a

Re: gnucash-2.3 + sql backend

On Sat, 6 Jun 2009 13:09:58 -0400 Phil Longstaff wrote: > On June 6, 2009 12:38:14 pm Klaus Dahlke wrote: > > Hi Phil, > > I digged around a bit and found the following statement in gnucash.trace: > > > > * 18:31:18 INFO [qof_session_load_backend] selected GnuCash > > Libdbi (POSTGRESQL) Backe

Re: gnucash-2.3 + sql backend

On June 6, 2009 05:16:33 pm Klaus Dahlke wrote: > On Sat, 6 Jun 2009 13:09:58 -0400 > > Phil Longstaff wrote: > > On June 6, 2009 12:38:14 pm Klaus Dahlke wrote: > > > Hi Phil, > > > I digged around a bit and found the following statement in > > > gnucash.trace: > > > > > > * 18:31:18 INFO [qof_

Re: gnucash-2.3 + sql backend

On June 6, 2009 12:38:14 pm Klaus Dahlke wrote: > Hi Phil, > I digged around a bit and found the following statement in gnucash.trace: > > * 18:31:18 INFO [qof_session_load_backend] selected GnuCash > Libdbi (POSTGRESQL) Backend * 18:31:18 CRIT > [pgsql_error_fn()] DBI error: could not connect

Fw: Re: gnucash-2.3 + sql backend

Should go to devel list as well - Forwarded Message From: Phil Longstaff To: gnucash-list Sent: Monday, June 1, 2009 10:26:45 AM Subject: Re: Re: gnucash-2.3 + sql backend This should be fixed for 2.3.1. For postgres, if the db did not exist, it didn't create it (and unfortun

Re: Another problem with scheme query and SQL backend

On May 31, 2009 06:53:23 am Erwin Rieger wrote: > Hi, > > i have another funny problem with querying data from scheme with the > (my)sql backend. > > The query from my previous posts do only return transactions that > are/were shown in the gui (ledger)! > > Steps to r

Another problem with scheme query and SQL backend

Hi, i have another funny problem with querying data from scheme with the (my)sql backend. The query from my previous posts do only return transactions that are/were shown in the gui (ledger)! Steps to reproduce: * install config.user from my previous post in ~/.gnucash * open a

Re: Scheme query, difference between XML and SQL backend, coredump

ll accounts, the sql backend coredumps with the same > query (see backtrace below). If the query is setup with accounts, the > query works with both the xml and sql backend. > > Scheme code to reproduce the error, this config.user adds two entries to > the Extensions menu. AQu

Scheme query, difference between XML and SQL backend, coredump

Version i've testet ist latest svn, 18095. -- Mit freundlichen Gruessen Erwin Rieger | Ingenieurbuero Rieger, Software Entwicklung | EMail: erwin.rie...@ibrieger.de -

Scheme query, difference between XML and SQL backend, coredump

Hi, i've noticed a different behavior of gnucash-backends when running querys from scheme. If a query is setup without accounts the xml backend selects data from all accounts, the sql backend coredumps with the same query (see backtrace below). If the query is setup with accounts, the

Re: gnucash-2.3 + sql backend

Hi Klaus, thanks for reporting these. On May 25, 2009 09:48:52 am Klaus Dahlke wrote: > Hi, > I'd like to test gnucash-2.3, in particular the sql backend (with > Postgres). I reading some older post I figured out to use --enable-dbi to > build the proper backend functionality.

Re: Problem with SQL backend on MacOX on PowerPC

On Fri, May 22, 2009 at 9:12 AM, Phil Longstaff wrote: > Mike Alexander has discovered that 2.3.0 using a libdbi-based SQL backend > does not work on a PowerPC using MacOX but probably other OSs as well.  The > problem is that libdbi assumes the wrong endianness.  He has submitted a &

Problem with SQL backend on MacOX on PowerPC

Mike Alexander has discovered that 2.3.0 using a libdbi-based SQL backend does not work on a PowerPC using MacOX but probably other OSs as well. The problem is that libdbi assumes the wrong endianness. He has submitted a patch to the libdbi project to fix it and attached it to bug #583150

Re: SQL Backend can't parse URL

Phil Longstaff wrote: > The interesting line in your log is: > * 07:22:41 INFO [init_sql_backend] -1 DBD drivers > found > > which means that there was some problem initializing libdbi. > > Your listing above shows that the dbd file are in /usr/local/lib/dbd. My > packages (ubuntu) put

Re: SQL Backend can't parse URL

On February 1, 2009 02:33:24 pm Derek Atkins wrote: > Phil, > > Quoting Phil Longstaff : > > which means that there was some problem initializing libdbi. > > > > Your listing above shows that the dbd file are in /usr/local/lib/dbd. My > > packages (ubuntu) put them in /usr/lib/dbd, so that is what

Re: SQL Backend can't parse URL

Phil, Quoting Phil Longstaff : > which means that there was some problem initializing libdbi. > > Your listing above shows that the dbd file are in /usr/local/lib/dbd. My > packages (ubuntu) put them in /usr/lib/dbd, so that is what I made the > default. I would assume that /usr/lib/dbd doesn't

Re: SQL Backend can't parse URL

On February 1, 2009 12:08:40 pm Mark Johnson wrote: > >>> On January 31, 2009 09:34:32 am Mark Johnson wrote: > I have built trunk rev 17855 with the wrong configure options. I > accidentally used the old --enable-gda instead of the correct > --enable-dbi. The file menu has a Datab

Re: SQL Backend can't parse URL

Phil Longstaff wrote: > On January 31, 2009 11:07:17 pm Mark Johnson wrote: > >> Phil Longstaff wrote: >> >>> Hmmm... 'configure' does allow any wrong options and does not seem to >>> flag it. What is *supposed* to happen (and what happens for me) is that >>> the 'Database Connection' menu

Re: SQL Backend can't parse URL

On January 31, 2009 11:07:17 pm Mark Johnson wrote: > Phil Longstaff wrote: > > Hmmm... 'configure' does allow any wrong options and does not seem to > > flag it. What is *supposed* to happen (and what happens for me) is that > > the 'Database Connection' menu item will be there, but insensitive u

Re: SQL Backend can't parse URL

Hmmm... 'configure' does allow any wrong options and does not seem to flag it. What is *supposed* to happen (and what happens for me) is that the 'Database Connection' menu item will be there, but insensitive unless '--enable-dbi' is specified. Can you send me your config.log and config.h?

SQL Backend can't parse URL

I have built trunk rev 17855 with the wrong configure options. I accidentally used the old --enable-gda instead of the correct --enable-dbi. The file menu has a Database Connection option and when I filled in its dialog's fields and clicked OK, I got a "can't parse URL error". If I haven't e

  1   2   3   4   >