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.
The core issue was that the delete visitor was never called because its parameter
type (char *) didn't match the boost::variant type (const char *).
Fixing the visitor's parameter type also require a const_cast
back to char * because that's what g_free takes as argument.
The rest of this commit is merely fixing KvpValue instantiations that
tried to create a char* KvpValue from a stack based const string instead
of a heap allocated one. That would bomb out on calling the
delete visitor.
Each was used exactly once and simply wrapped a function call.
Also replace static function time_parse_failure that just returned a
constant with the constant.
First, save isn't necessary if the book is dirty, so don't... but that
means that the book has to be marked dirty after a session swap. No more
laziness.
Second, regardless of the outcome of inner_main_add_price_quotes the
session must be destroyed to remove the lock.
A couple of cleanups in QofSessionImpl::save as well: Rewrote the
descriptive comment to reflect how it really works when the backend has
gotten disconnected and removed the superfluous qof_book_set_backend
with the backend that we'd *just gotten from the book*.
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.
Provide a backup recovery function that instead of dropping primaries
and restoring backups merges the primaries and backups. This should
handle a worst-case safe-save failure where the backup tables don't
have a complete set of rows for some reason.
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.
Removes a public function, GncDbiSqlConnection::table_manage_backup that
should have been private in the first place.
Better encapsulates table renames and drops with private functions and
handles cases where there exist some primary tables and some backup tables.
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.
This commit contains another round of cleanups in the
timespec to time64 conversion. There were a number of
false assumptions that time64 = 0 would be a bad date
in the xml parser. This commit corrects enough of them to
eliminate the bug. Further cleanup is probably advised but
can be done at a later stage.
First, remove the unnecessary locale push & pop on <CT_TIME64>load.
Second, the registry accesses were caused by using g_win32_get_locale
to convert the Microsoft locale strings to POSIX ones. We don't care
what kind of string we get as long as we can pass it back to setlocale,
so remove that.
Third, gnc_push/pop_locale were used only in backend/dbi in a
very limited way and did much more than was necessary, so
convert them to C++ inlines in gnc-backend-dbi.hpp that does
only what we need them to.
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.
