GDA missing records retest (long)
mrj001 at shaw.ca
Sat Apr 19 13:53:28 EDT 2008
Phil Longstaff wrote:
> Mark Johnson wrote:
>> While looking at the PostgreSQL error log, I also noted the following error:
>> ERROR: relation "books" does not exist
>> STATEMENT: INSERT INTO books (guid, root_account_guid,
>> root_template_guid) VALUES ('be5d5b80c1a8f36ec33139cb27440ca7',
>> '8f436420bffa2ba45515192c895b083b', '2c54584a7995ce449f2fd371771ef562')
>> PROBLEM: the books table is not created. I checked all 3 DBs.
> When the gda backend saves to a db, it deletes all of the tables and
> then recreates them. Between these, it calls a libgda function to
> refresh its knowledge of the scheme. This function retrieves the new
> schema and removes entries from its internal table list which are not in
> the new schema. Unfortunately, this function has a bug so that all
> entries except the 2nd one are removed. Then, when the gda backend
> tries to recreate the tables, it doesn't recreate that table because it
> "already exists". This means 1 table is not created until the next time
> the db is opened. At this time, the missing table is not in the libgda
> table list, so the gda backend creates it.
> When I run into this problem, I see it with the billterms table. I',
> not sure, but I guess it is possible that it might also affect the books
> table if it was the 2nd table in the list (accounts is 1st).
This might be the same problem. I do have a billterms table even though
I don't use it. It is the second in the list when I list the tables
using psql. They are listed in alphabetical order. I am assuming that
the list retrieved by libgda would be in the same order.
I was using libgda-3.1.2. I suppose they might have changed the bug to
be the third item in the list instead of the second. Are you using
> As I workaround to the bug, I could try a direct operation on the table
> and see if there is the right error message. The real fix is to fix the
> libgda bug, of course.
Now, the libgda project is busy on version 4, which no longer contains
the GdaQuery object. I don't expect much bug fixing of version 3, but
it would be very much needed for gnucash. I do not think that version 3
is ready for prime time, given the number of bugs this project has found.
The providers are also being redone. Certainly, the PostgreSql provider
is much more efficient.
The API is still evolving (as witness the removal of GdaQuery). There
has been some discussion on the libgda mailing list of trying to get
version 4 included with a release of gnome (2.26 I think it was).
Any thoughts of moving to version 4?
More information about the gnucash-devel