The linkage problem was caused by the symbol appearing in
libgncmod-backend-dbi.dll but not libgncmod-backend-dbi.dll.a.
Incoprorating gnc-backend-dbi.c as a source file to the test program
instead of linking its library resolved the issue.
SQL_OPTION_TO_REMOVE is substituted during preprocessing so it can be
inlined in the string initialization, no need for heap allocation or
runtime composition.
Update this test to use strftime so the format can be specified as ctime
was using a space in front of the month number. Also add a '\n' to the
end of msg2 as the PINFO in Transaction.c line 1940 has one.
The recursive quickfill code had several expensive
function calls that could be moved out of the recursion.
In addition using qof's string cache would result in
an expensive call to g_str_hash for each iteration, which
quickly degraded performance on huge accounts.
I have removed the use of qof's string cache from quickfill
which considerably improves performance of opening the
register for a huge account at the expense of slightly
more memory overhead.
For example I saw register load time reduce from 75 seconds
to 2 seconds, while using 20kb more memory.
When importing MT940 files, AqBanking will (sometimes?) put
all transactions under a single AccountInfo, even when there
are multiple accounts in the file. Luckily the correct account
information can be recovered from the transaction information.
This patch will try to use the account information in the
transaction before trying to use the saved account state.
Patch by Jethro Beekman.
On the theory that in countries where multiple languages are in use similar
date and number formats will apply regardless of language, and especially
that the default currency will be the same regardless of language.
Also ensure that the specified language is in the list passed to gettext;
the net effect of which is that the user will effectively get the requested
localization behavior.
This commit improves payment type deduction by first checking
whether an AR or AP account is found in the transaction.
If not, fall back to previous heuristic of positive action
means customer payment, negative action means vendor
action. The logic can still go wrong (no means to declare
an employee payment, and credit notes are interpreted as
opposite sign payments). Needs a follow up to fix that.
If the transaction is marked as a (business feature) payment,
extract the address of the bill/invoice associated with the
payment, or the owner if there's no bill/invoice yet.
