If a function that returns an allocated pointer is passed directly into
something that does not take ownership of the pointer, the allocation is
leaked. This can be fixed by assigning the pointer to a new variable
and freeing it after operation on the memory.
In file included from gnucash/gnome-utils/dialog-options.cpp:34:
gnucash/gnome-utils/dialog-options.hpp:55:10: warning: private field 'toplevel' is not used [-Wunused-private-field]
bool toplevel;
^
In file included from gnucash/import-export/csv-imp/gnc-imp-props-price.cpp:42:
gnucash/import-export/csv-imp/gnc-imp-props-price.hpp:113:10: warning: private field 'created' is not used [-Wunused-private-field]
bool created = false;
^
libgnucash/backend/dbi/gnc-dbisqlconnection.cpp:53:29: warning: private field 'm_conn' is not used [-Wunused-private-field]
const GncSqlConnection* m_conn = nullptr;
^
libgnucash/backend/sql/test/utest-gnc-backend-sql.cpp:81:33: warning: private field 'm_conn' is not used [-Wunused-private-field]
const GncMockSqlConnection* m_conn;
^
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.
