Move all of the #include <glib> to before the extern "C" blocks
so that the include guards will protect against headers inside
the extern "C" block also including glib.h.
to mysql database.
It's more general, any save-as to a different backend type, i.e.
xml->sql or sql->xml, left the previous book locked.
Ensure that the session is ended and the book unlocked in the
backend's destructor. This also fixes a memory leak in the SQL
backend because the GncSqlConnection wasn't being deleted.
when database already exists.
Crashed because of dereferencing GncSqlBackend::m_conn when it's nullptr
after the DB create failed. Protect all such dereferences.
For clarity. In so doing found the backend behavior a bit inconsistent
so it's modified to do what the enum values indicate.
In the course of changing the various calls I found some implementation
errors in the back end and corrected them.
There are a very few left that need deeper study, but this gets
rid of most of the noise. For the most part it's just getting rid of
extra variables or removing an assignment that is always
replaced later but before any reads of the variable. A few are
discarded result variables.
And don't ask to save a not-dirty or empty book, fixing
Bug 794870 - If no book is opened, gnucash still asks if the user wants
to save changes when opening a file
That is let the percentage increase gradually. The current granularity is still
very rough, but at least it gives an indication of getting closer to fully
loading the data. The previous configuration on the other hand only suggested
something was happening but with no indication where in the load process
gnucash was.
This prevents calling xaccAccountRecomputeBalanceInCurrency on each split that gets added,
which was exponentially increasing load times. On a huge test book the
load time dropped from 53 minutes to 1m20s.
Change all instances of bugzilla.gnome.org to bugs.gnucash.org, reflecting
our migration to a self-hosted bug tracker.
Inform the Translation Project Coordinator at release that this affects
translatable strings and that all message catalogs have been updated.
In addition to not begining to edit already-loaded transactions,
don't try to load splits that are already loaded. It shouldn't
be possible to load a transaction without also loading its splits.
The underlying problem was that the vendor object remained in infant state
That confused the backend code so it used an sql INSERT statement instead
of an UPDATE statement to write back the changes. As the object already
existed in the db this would fail.
The fix is to ensure the object doesn't remain in infant state during
sql loading. See the bug report for a more detailed explanation.
An extra XaccTransBeginEdit, never committed, for transactions that
the backend tried to load when they were already there. That made
the register think that something else had it open.
Instead of reporting an error and declining to load the file (XML)
or failing to enter a value (SQL) when a bad date is found in the
database, use a 0 time stamp (1970-01-01 00:00:00 UTC). Adds a warning
in SQL backends; there was one already in XML.
We don't use floats in GnuCash, we use doubles (and those as little as
possible), but dbd-sqlite3 is broken in that it stores only floats.
Simply casting floats to doubles introduces bogus additional digits
that can cause round-trip tests to fail. Instead convert floats to
doubles by multiplying by 10E6, rounding, then dividing by 10E6.
SQLite backend.
Release Note: This bug caused data loss if you saved your SQLite3
database to a different file or database.
The problem is that in SQLite3 (though not in MySQL or PgSQL) the
subquery ((SELECT DISTINCT guid FROM transactions)) (note the double
parentheses) returns only the first guid in the subquery's results.
Some transactions are loaded by special queries and those queries are
also used to retrieve the transaction's slots so they weren't affected.
properly - corrupted business data
Turned out to be a pointer/value mismatch between <CT_NUMERIC>load()
and most of the setter functions, so the address was getting set
as the value.
This crash started to appear as of commit 80dbb9940b because the sequence
of split loading has changed as a result of the query optimizations.
Invoice transactions get loaded before the general transaction loading happens.
However because of this, when an invoice transaction was encountered again
during general transaction loading, it was (correctly) not created again
AND (incorrectly) not opened for subsequent editing. This caused
an assert to fail when the splits for this transaction are loaded
shortly afterwards. The solution is simply to ensure all transactions
are opened for editing during the general transaction loading call.
