Multi-currency transactions with trading accounts from 2.4.13 getting messed up in latest 2.6.3

[Mark]

On 2014-06-22 09:44, John Ralls wrote:
> On 21 Jun 2014, at 18:00, Mark <msalists at gmx.net> wrote:
>
>> Hi David,
>>
>> I'm using sqllite files rather than XML, so they are not that straight-forward to open.
>> I also don't think that the exchange rate is stored in each transaction - at least not explicitly. It's there implicitly, of cource, simply because there are 2 amounts in the trading accounts of the respective currencies.
>>
>> Either way - I'll just try to put out as many details as I can, hoping that the team will pick this up and release a fix (if it is indeed a bug). I don't want to mess with my files and break something else on the way....
> So two revelations: No SX and you're using SQLite. That rather changes the situation entirely.
>
> The fact that you're not using SX means that it's not related to any of the three bugs I listed yesterday; I think that's the avenue David was heading down as well.
>
> If it is indeed a bug it needs a bug report. Once this email thread dies out there will be nothing to remind us to go looking for whatever the problem is.
>
> You're correct that price isn't stored; there's a price field in the register, but it's calculated from the ratio of amount and value, which are stored.
>
> Editing Forex transactions is difficult because only the value field is visible; this difficulty is compounded by trading accounts, which add more active amount fields. Worse, it's those invisible amount fields that have to balance, so you have to use the transfer dialog (which you can open by selecting "edit exchange rate" from each split's context menu) to inspect it.
>
> Regards,
> John Ralls
>
>
I submitted Bug 732058 https://bugzilla.gnome.org/show_bug.cgi?id=732058 
for this.
I also ran some queries in SQLite Database Browser and added the results 
as CSV attachments.
Based on the queries and results I suspect that 2.6.3 is breaking 
something somewhere. I could not find any indication of an already 
existing inconsistency in the 2.4.13 data file.