when upgrading from 2.6 to 3.3 with a Postgres backend, all splits are blank and transactions show zero. Had the same issue with 2 separate Postgres databases. Reported on IRC channel and was able to achieve a workaround solution by reverting to 2.6, saving as XML, upgrading to 3.3, and saving as Postgres.
locale = en_US.UTF8 OS = Ubuntu 18.04
I'm not able to replicate this when starting from GnuCash 2.6.21 using Postgres 9.6.10 on Debian 9. What version of Gnucash 2.6 and what version of Postgres?
gnucash version 2.6.19 postgres version 10.6 Thanks!
I can't duplicate that setup. I can run GnuCash2.6.19 on the Debian 9 VM and write to a Postgres11.1 DB on a Debian Sid (unstable) VM, and then open it with GnuCash3.3 on the latter. That works mostly fine. Mostly because if I start with a Postgres9.6 database on the Debian 9 VM and save it to the Postgres11.1 server the id_seqs for the tables that use SEQUENCE primary keys don't get set correctly and GnuCash won't write to them. If I save directly from an XML file I don't see that problem. Do you still have the 2.6-created databases available? If so, can you start GnuCash 3.3 with '--log gnc.backend.dbi=debug", try to open one of them, and then attach the resulting tracefile (https://wiki.gnucash.org/wiki/Trace_file)?
Okay, will be a bit before I can test it out, my test box is being used for another project at the moment. Will report back. Thanks
Created attachment 373197 [details] Tracefile Here is the tracefile when attempting to open my old database in 3.3. Thanks!
I built version 3.3 from source on my Ubuntu 16.04 system and experienced the same issue as going from 16.04 & 2.6.19 to 3.3 on Ubuntu 18.04. I was able to workaround the issue by saving as XML, opening the XML in 3.3, and re-saving as postgres. Thanks again, Justin
Please run the following in the psql command-line tool after connecting to the database: SELECT count(splits.guid) FROM splits INNER JOIN transactions ON splits.tx_guid = transactions.guid; SELECT count(guid) FROM splits; What values do you get?
3752 for both queries.
So the problem isn't the join. Try SELECT select transactions.description, splits.amount, splits.value FROM splits INNER JOIN transactions ON splits.tx_guid = transactions.guid LIMIT 20; to see if the amounts and values are being properly retrieved.
uh, amount and value aren't valid columns in the splits table. I can run it for splits.quantity_num, splits.value_num and values are returned...
Sorry, I dropped the ball on this, but I think that we're long past the 2.6->3.x database backend migration, so marking it obsolete.
