unittests for mysql and postgresql backends
Will this change require a running mysql and pg instance to "make
check"? (I haven't looked closely enough at the code). Will it still
pass if you don't have the mysql or pg dbd backends?
-derek
The tests for mysql and pgsql will only
Add unittests for mysql and postgresql backends
Will this change require a running mysql and pg instance to "make
check"? (I haven't looked closely enough at the code). Will it still
pass if you don't have the mysql or pg dbd backends?
-derek
--
Derek Atkins, SB '93 MI
On Wednesday 8 September 2010, Paddy Walker wrote:
> I am using Gnucash 2.3.13 in Fedora 13.
> I wish to try the "save as" and select postgresql.
> I have a postgresql server running. I have established a role in my user
> name. I have created a database "gnucash".
Do you have the postgres DBD (DBI Driver) installed?
-derek
On Wed, September 8, 2010 1:05 pm, Paddy Walker wrote:
> I am using Gnucash 2.3.13 in Fedora 13.
> I wish to try the "save as" and select postgresql.
> I have a postgresql server running. I have established a role in
I am using Gnucash 2.3.13 in Fedora 13.
I wish to try the "save as" and select postgresql.
I have a postgresql server running. I have established a role in my user name.
I have created a database "gnucash".
I still do not get postgresql listed as an option in the drop down
Hi,
Christian Stimming writes:
> I've asked this before, and the conclusion was that a lock on the full
> database is probably easiest and also sufficient. Is such a lock
> already in place? Will it work for all three existing dbi drivers?
>
> I couldn't recall reading about this in the commit l
big red warning
sign in case it already exists. Because of the non-existence of multi-user
capabilities, we *must* ship with a similar database lock in case the backend
is not XML but sqlite3 or mysql or postgresql (depending on the available dbi
drivers).
I've asked this before, an
If you have downloaded 2.3.11 and are using a mysql or postgresql
backend with it, then gnucash will *not* automatically load your
database when you start gnucash. This is due to a change in how the
database reference is formatted internally (to make more consistent).
Instead, you will need to
On Tue, Feb 23, 2010 at 7:07 AM, Conrad Canterford
wrote:
> On Sun, 2010-02-21 at 18:37 +, Mike Evans wrote:
>> On Sunday February 21 2010 17:22:59 Donald Allen wrote:
>> > On Sat, Feb 20, 2010 at 5:48 PM, wrote:
>> > > A question for you folks --
>> > > Does anyone know how far back a data
On Sun, 2010-02-21 at 18:37 +, Mike Evans wrote:
> On Sunday February 21 2010 17:22:59 Donald Allen wrote:
> > On Sat, Feb 20, 2010 at 5:48 PM, wrote:
> > > A question for you folks --
> > > Does anyone know how far back a data file must go before the SQL
> > > interface starts truncating dat
t) exhibits the incorrect behavior. Doing a 'Save As' sqlite3
> >> and then restarting gnucash produces the same truncation behavior
> >> described in bug 609583, which is not surprising, since I saw nothing
> >> in the 2.3.9 or 2.3.10 release notes about this
Doing a 'Save As' sqlite3
>> and then restarting gnucash produces the same truncation behavior
>> described in bug 609583, which is not surprising, since I saw nothing
>> in the 2.3.9 or 2.3.10 release notes about this issue having been
>> fixed (I first observed it
enamed Bug 609583 to "Database backend loses data", because
> after I entered the bug, I did the same test with sqlite3 and observed
> the same truncation behavior I saw with postgresql. So the issue
> described in that bug appears to be above the database-specific code.
>
>
base backend loses data", because
after I entered the bug, I did the same test with sqlite3 and observed
the same truncation behavior I saw with postgresql. So the issue
described in that bug appears to be above the database-specific code.
/Don
__
w. No display of the chart of accounts, nothing.
> This is a step backward from 2.3.8, where I was able to get much
> further, displaying accounts normally, and then saving to either
> postgresql or sqlite3, where I observed the truncation issue we've
> been discussing.
>
Aside
displaying accounts normally, and then saving to either
postgresql or sqlite3, where I observed the truncation issue we've
been discussing.
/Don
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
I have gnucash 2.3.4 connecting to a pgsql server. Using an existing
datafile I connected to a blank pgsql db using the "Save As" dialog. It
created the structure and inserted the data well AFAIK. Initially, it
looked OK and I saved as an xml file before exiting. When I re
connected to the
7;m using
> dd/mm/yy format). After saving to postgresql and restarting GC, the same
> transaction now has "forever" selected. "Since last run" now contains
> all the occurances of this transaction from 28/2/08 until now.
>
> I was running wi
I found (one of) the corruptions that I mentioned in my email of yesterday!
I have an existing GC XML file that contains a scheduled transaction
that had "repeats until" selected with a date of 28/02/08 (I'm using
dd/mm/yy format). After saving to postgresql and restarti
vel@gnucash.org; plongst...@rogers.com
> *Sent:* Tuesday, July 14, 2009 2:26:17 PM
>
> *Subject:* Re: Installing GNU Cash with PostGreSQL
>
> I have PostgreSQL configured on a linux server. when I do the save as
> dialog in gnucash on winXP pro to save on that server gnucash
for a file named
gnucash.trace.XX where XX is some 6 character code).
Phil
From: Brian Amos
To: gnucash-devel@gnucash.org; plongst...@rogers.com
Sent: Tuesday, July 14, 2009 2:26:17 PM
Subject: Re: Installing GNU Cash with PostGreSQL
I have PostgreSQL con
I have PostgreSQL configured on a linux server. when I do the save as
dialog in gnucash on winXP pro to save on that server gnucash crashes. Is
this error related to
https://lists.gnucash.org/pipermail/gnucash-devel/2009-July/025821.html?
using gnucash on winXPpro tablet edition.
postgres 8.2.5
Thanks for the instructions. I was able to get to the dialog to save as a
PostGreSQL database file. Now I have to get PostGreSQL configured so I can use
it.
Regards,
Anders
--- On Thu, 7/9/09, Phil Longstaff wrote:
From: Phil Longstaff
Subject: Re: Installing GNU Cash with PostGreSQL
To
On July 9, 2009 08:24:57 pm Anders Johansson wrote:
> How do I install GNU Cash to use PostGreSQL as the backend? I am running
> Win XP Pro, service pack 3. I currently have GNU Cash 2.2.9 and willing to
> experiment with 2.3.2, but would like to try it using the PostGreSQL
> backend
Hi Anders,
I believe the SQL backend uses libdbi, so that might be a good
starting place. That's about all the advice I can offer as I don't use
Windows.
- Albert
On Thu, Jul 9, 2009 at 8:24 PM, Anders Johansson wrote:
> How do I install GNU Cash to use PostGreSQL as the backend?
How do I install GNU Cash to use PostGreSQL as the backend? I am running Win
XP Pro, service pack 3. I currently have GNU Cash 2.2.9 and willing to
experiment with 2.3.2, but would like to try it using the PostGreSQL backend.
Thanks,
Anders
As of rev 17323, the gda-dev2 backend supports mysql and postgresql databases
again. Despite the name, it uses the DBI library
(http://libdbi.sourceforge.net).
In the file menu, the 'Database Connection' menu entry allows you to save to or
load from one of these databases. This en
Please see at attachment for a patch to add AUTOINC (set type to
serial) on Postgresql.
Hops this helps to Phil in the problem to autoincrement Pkey at
Postgresql GDA provider,
This will close Bugs: #515306 and #515528
Just wait for gnome-db developers to review it.
2008/2/7, Mark Johnson
On Feb 11, 2008, at 9:09 PM, Mark Johnson wrote:
I'd be interested in any benchmarks you have. Re SQL statement
length: the mysql document says there is a 16MB limit and I didn't
see
any limit in the sqlite documentation. Is there a way of doing
something like:
SELECT DISTINCT tx_guid FRO
KEY will create implicit index
>>> "billterms_pkey" for table "billterms"
>>> but my data seems to load correctly. Note that I don't actually have any
>>> billing terms in my data.
>>>
>>> I'll do some more testing.
>>>
>>
Graham Leggett wrote:
> Derek Atkins wrote:
>
>> I think the question was more: Does every table have to HAVE
>> a primary key? Yes, the primary key must be unique, but what
>> if a table has no primary key? Is that still okay?
>
> It's perfectly ok, yes - but primary keys are used heavily for
Derek Atkins wrote:
I think the question was more: Does every table have to HAVE
a primary key? Yes, the primary key must be unique, but what
if a table has no primary key? Is that still okay?
It's perfectly ok, yes - but primary keys are used heavily for
optimisation. Without them, perfor
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "billterms_pkey" for table "billterms"
> but my data seems to load correctly. Note that I don't actually have any
> billing terms in my data.
>
> I'll do some more testing.
>
> Thanks,
&
Derek Atkins wrote:
> Mark Johnson <[EMAIL PROTECTED]> writes:
>
>
>> Phil Longstaff wrote:
>>
>>> The slot_id is used to provide a unique primary key. I don't know if it
>>> would work to have the slots table have *no* key, but have an index on
>>> the obj_guid field. The obj_guid fiel
Phil Longstaff wrote:
> Graham Menhennitt wrote:
>
>> saved. I then try to load from the DB using a command line parameter of
>> the DSN. It runs for a few seconds and then crashes with a segmentation
>> violation.
>>
> I just committed rev 16942 which should fix this. I don't use the
>
On Thu, Feb 14, 2008 at 12:45 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Mark Johnson <[EMAIL PROTECTED]> writes:
>
> > Phil Longstaff wrote:
> >> The slot_id is used to provide a unique primary key. I don't know if
> it
> >> would work to have the slots table have *no* key, but have an index
Mark Johnson <[EMAIL PROTECTED]> writes:
> Phil Longstaff wrote:
>> The slot_id is used to provide a unique primary key. I don't know if it
>> would work to have the slots table have *no* key, but have an index on
>> the obj_guid field. The obj_guid field can't be the primary key because
>> I
Phil Longstaff <[EMAIL PROTECTED]> writes:
> Derek, any thoughts on the 3.x vs 1.3.x question (from another thread)?
> If we try to target the gda backend for GC 2.4 (I saw a suggested
> release date near the end of the 2008), what is the "supported" set of
> linux releases (fedora 6 and above
Graham Menhennitt wrote:
> G'day all,
>
> I've successfully built the gda branch version 16939 from SVN. I can run
> it with a normal gnucash data file as the command line parameter and
> then save to a PostgreSQL DSN using the File->Database Connection menu
> item.
l be posting my
>> results so far (i.e. without any additional indices) soon (hopefully
>> later today). Obviously, they can't include the complete series of
>> queries for PostgreSQL. I have done MySql and SQLite, but need to run
>> the partial series for PostgreSQL.
>
. I will be posting my
> results so far (i.e. without any additional indices) soon (hopefully
> later today). Obviously, they can't include the complete series of
> queries for PostgreSQL. I have done MySql and SQLite, but need to run
> the partial series for PostgreSQL.
>
an index to see
if it helped. I haven't got that far though. I will be posting my
results so far (i.e. without any additional indices) soon (hopefully
later today). Obviously, they can't include the complete series of
queries for PostgreSQL. I have done MySql and SQLite, but need to ru
Phil Longstaff wrote:
> Mark Johnson wrote:
>
>> Previously, I had suggested a workaround for the empty PostgreSQL slots
>> table problem.
>>
>> I have now tried the work-around for the empty slots table problem with
>> PostgreSQL. The type SERIAL is
Quoting Greg Troxel <[EMAIL PROTECTED]>:
> Saving to the db deletes all tables and then recreates them. It
> therefore deleted the slot_id without the default value. It wouldn't
> have touched the sequence. I'll need to build your workaround into a
> rev and then let you try it. There's al
Saving to the db deletes all tables and then recreates them. It
therefore deleted the slot_id without the default value. It wouldn't
have touched the sequence. I'll need to build your workaround into a
rev and then let you try it. There's also an argument to be made that I
should
Derek Atkins wrote:
> Hi,
>
> Phil Longstaff <[EMAIL PROTECTED]> writes:
>
>
>> Saving to the db deletes all tables and then recreates them. It
>> therefore deleted the slot_id without the default value. It wouldn't
>> have touched the sequence. I'll need to build your workaround into a
>>
Hi,
Phil Longstaff <[EMAIL PROTECTED]> writes:
> Saving to the db deletes all tables and then recreates them. It
> therefore deleted the slot_id without the default value. It wouldn't
> have touched the sequence. I'll need to build your workaround into a
> rev and then let you try it. Ther
Mark Johnson wrote:
> Previously, I had suggested a workaround for the empty PostgreSQL slots
> table problem.
>
> I have now tried the work-around for the empty slots table problem with
> PostgreSQL. The type SERIAL is simply a convenience, and not a real
> type. I had hop
Previously, I had suggested a workaround for the empty PostgreSQL slots
table problem.
I have now tried the work-around for the empty slots table problem with
PostgreSQL. The type SERIAL is simply a convenience, and not a real
type. I had hoped the convenience extended to ALTER TABLE, but it
figure script will
> need to detect 1.3.x vs 3.x, and the gda backend will need to handle
> those 2 libgda revs and the 3 backends (sqlite/mysql/postgresql) using
> SQL only (no GdaQuery). I should be able to set things up with most
> of the code in common and only a few special cases
G'day all,
I've successfully built the gda branch version 16939 from SVN. I can run
it with a normal gnucash data file as the command line parameter and
then save to a PostgreSQL DSN using the File->Database Connection menu
item. By looking in the DB using psql, it seems that my
> I had compiled the V4 branch with the idea of testing it with
> gnucash-gda. Not necessarily a good idea as it would be testing both
> gda and gnucash-gda simultaneously. Thus, so far, I have not
> installed it. As you will see below, I am having enough trouble with
> the curr
g it with
gnucash-gda. Not necessarily a good idea as it would be testing both
gda and gnucash-gda simultaneously. Thus, so far, I have not installed
it. As you will see below, I am having enough trouble with the current
(3.1.2) PostgreSQL provider.
>>>
>>> It looks as th
Mark Johnson wrote:
> Phil Longstaff wrote:
>> Mark Johnson wrote:
>>> The slots table includes an id field which is "auto_increment".
>>> PostgreSQL does not implement that keyword. Instead, it appears to
>>> accept it, but ignore it when c
Phil Longstaff wrote:
> Mark Johnson wrote:
>> The slots table includes an id field which is "auto_increment".
>> PostgreSQL does not implement that keyword. Instead, it appears to
>> accept it, but ignore it when creating the table. (This may actually
>
Mark Johnson wrote:
> The slots table includes an id field which is "auto_increment".
> PostgreSQL does not implement that keyword. Instead, it appears to
> accept it, but ignore it when creating the table. (This may actually be
> libgda's PostgreSQL provider doing
The slots table includes an id field which is "auto_increment".
PostgreSQL does not implement that keyword. Instead, it appears to
accept it, but ignore it when creating the table. (This may actually be
libgda's PostgreSQL provider doing that.) Gnucash-gda relies upon t
Quoting Christian Stimming <[EMAIL PROTECTED]>:
If it were much more helpful to have such an extra dialog, compared to not
having one, then we might agree to add those strings. But frankly I don't see
much value in that. We could add an AC_MSG_WARN if --enable-sql is used
(probably in the messag
Am Donnerstag, 25. Mai 2006 16:07 schrieb Derek Atkins:
> >> I've been trying to see how far I can bring the postgres backend in
> >> the past couple days, on the misc-backend branch.
>
> I know it's past string freeze, but. Is it potentially worthwhile
> to pop up a dialog when the user opens
Christian Stimming <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 25. Mai 2006 01:28 schrieb Chris Shoemaker:
>> I've been trying to see how far I can bring the postgres backend in
>> the past couple days, on the misc-backend branch.
>>
>> Currently, I've been successful at:
>>
>> - opening a data
Am Donnerstag, 25. Mai 2006 01:28 schrieb Chris Shoemaker:
> I've been trying to see how far I can bring the postgres backend in
> the past couple days, on the misc-backend branch.
>
> Currently, I've been successful at:
>
> - opening a database created with 1.8
> - saving the opened database a
Devs,
I've been trying to see how far I can bring the postgres backend in
the past couple days, on the misc-backend branch.
Currently, I've been successful at:
- opening a database created with 1.8
- saving the opened database as an xml file
- creating a new database with 1.9
Caveats:
1)
Neil Williams <[EMAIL PROTECTED]> writes:
> I think extending the auto-complete within the business code to re-use the
> cache between business windows would be a very useful addition to GnuCash.
I think *IMPLEMENTING* autocompletion in the business ledger would
be useful.. Right now it's not i
On Sunday 17 April 2005 4:01 am, Brian wrote:
> On Sat, 2005-16-04 at 17:03 +0100, Neil Williams wrote:
> > On Saturday 16 April 2005 4:41 pm, Brian wrote:
> > > So far I have found that in entering a new vendor bill that the
> > > descriptions have a short term memory. It is only for the current
On Sat, 2005-16-04 at 17:03 +0100, Neil Williams wrote:
> On Saturday 16 April 2005 4:41 pm, Brian wrote:
> > So far I have found that in entering a new vendor bill that the
> > descriptions have a short term memory. It is only for the current bill!
> > Rarely would I have to enter the same descri
On Saturday 16 April 2005 4:41 pm, Brian wrote:
> So far I have found that in entering a new vendor bill that the
> descriptions have a short term memory. It is only for the current bill!
> Rarely would I have to enter the same description twice in the same
> bill, but would enter the same descrip
above could be implemented in an xml database for smaller
requirements but would be more suitable to a regular database for larger
numbers of vendors/items to remember. This brings up the postgersql
question. Is there still interest/work on bringing the postgresql
integration up to date with the
Neil Williams <[EMAIL PROTECTED]> writes:
> On Sunday 20 February 2005 4:51 am, Derek Atkins wrote:
>> "Matthew Vanecek" <[EMAIL PROTECTED]> writes:
>> > Specifically, I'm working on GDA support (www.gnome-db.org), which
>> > encompasses P
On Sunday 20 February 2005 4:51 am, Derek Atkins wrote:
> "Matthew Vanecek" <[EMAIL PROTECTED]> writes:
> > Specifically, I'm working on GDA support (www.gnome-db.org), which
> > encompasses Postgresql, mySQL, SQLite, and I believe Oracle and DB2. So
&g
"Matthew Vanecek" <[EMAIL PROTECTED]> writes:
> Specifically, I'm working on GDA support (www.gnome-db.org), which
> encompasses Postgresql, mySQL, SQLite, and I believe Oracle and DB2. So
> far, I've got the basics (Accounts, Transactions, Splits, KVP) loading
ite support? If it is
>> being actively developed, what is its status and what problems still
>> need to be solved?
>
> One developer is actively working on combined PG/SQLite support.
> Hopefully he'll chime in and provide a more detailed answer.
>
> -derek
Specifi
"Burress, Tobias" <[EMAIL PROTECTED]> writes:
> I've browsed through the archives (patches and devel) for the past few
> months and didn't see much discussion on this. Is psql support still
> being pursued, or is it being deferred to SQLite support? If it is
> being actively developed, what is i
I've browsed through the archives (patches and devel) for the past few
months and didn't see much discussion on this. Is psql support still
being pursued, or is it being deferred to SQLite support? If it is
being actively developed, what is its status and what problems still
need to be solved?
_
On 23 Jun 2001 17:50:23 -0700, Alex Zepeda wrote:
> So I felt a bit masochistic today and decided to have another go at
> building everything. So far the biggest problem has been the dependency
> on non-standard functions like atoll and stpcpy. atoll is easy to
> replace, since strtoll is ISO C
So I felt a bit masochistic today and decided to have another go at
building everything. So far the biggest problem has been the dependency
on non-standard functions like atoll and stpcpy. atoll is easy to
replace, since strtoll is ISO C compliant (C99). stpcpy is a bit more
difficult since it'
> If not, I spoke to both camps, and the MySQL people said that they
> already have a patch that'll allow embedded use. They just have to
> get around to auditing and incorporating it, and the PostgreSQL people
> said that you could pretty easily launch a copy of postgresql in a
&g
he data file - the Sequential Access - then add index entries -
the I stands for Indexed - to enable rapid finding of the correct file
offset. More advanced versions intelligently reuse the gaps left by
deleted records rather than always sequentially appending; more primitive
versions (eg, PostgreS
> For example filling in a sequential primary
> key properly is a typical case, each database provides its own facility for,
> Oracle sequences, MSSQL identity columns, etc.
>
Just a note as a gainfully employed DBA:
_DO_NOT_USE_SEQUENTIALLY_INCREASING_COLUMNS_AS_PRIMARY_KEYS_
Please. Th
w embedded use. They just have to
get around to auditing and incorporating it, and the PostgreSQL people
said that you could pretty easily launch a copy of postgresql in a
"sandbox" and talk to it from your app. With a tiny amount more
coding effort, you could fix it so that you tal
Christopher Browne wrote:
[...]
> The options that leap to mind are:
> a) Berkeley Sleepycat DB. This tends to be _included_ with GNU-related
>systems, and provides, in its latest versions, transaction logging,
>locking, and all that sort of thing. There has been some discussion
>of
y-oriented DBMSes)
e) InterBase was designed to work with embedded apps
f) I'm interested to see what SAP does with sapdb, apparently soon
to be available under GPL.
All of these are designed with more of a view to embedding them in other
applications than was the case for MySQL or Postg
81 matches
Mail list logo
