Backport or not ?

Geert Janssens janssens-geert at
Fri Jun 22 13:44:58 EDT 2012

On 22-06-12 19:01, John Ralls wrote:
> On Jun 22, 2012, at 5:43 PM, Geert Janssens<janssens-geert at>  wrote:
>> On 22-06-12 18:11, Mike Alexander wrote:
>>> On Jun 22, 2012, at 4:41 AM, Geert Janssens wrote:
>>>> I wasn't very awake apparently yesterday when I wrote my first message. David's mail triggered me to actually *test* how 2.4.10 would react on the new data format:
>>>> - It opens the file without any warning
>>>> - The scheduled transaction is missing the parameter (weekly adjust)
>>>> - But if you don't change the scheduled transaction, the parameter won't get lost either: reopening the file again in trunk shows the parameter is still saved.
>>>> - Back to 2.4.10: when exiting the application, it spews a few assertion failures in g_hash_for_each:
>>>> CRIT<GLib>   g_hash_table_foreach: assertion `version == hash_table->version' failed (3 times)
>>>> - Trying to modify or create a scheduled transaction in 2.4.10 with the new data fails with a vague error that the database transaction failed.
>>> Did you try this with an XML file or only a database?  It seems to me that the XML backend might lose this field when the file is saved, even if the scheduled transaction isn't edited but I haven't tried this to be sure.
>> You are right. When opening a new datafile with 2.4.10 and then saving it as xml, the field is lost. This is similar to opening an old format xml datafile in 2.4.10, saving it as sql and saving it back as xml. Because the same can happen in 2.4.10, I wouldn't consider this a regression.
>> But I think writing a faq entry for it may be useful, depending on how many people actually hit all of these conditions:
>> - working in sql in 2.4.11
>> - saving to xml in 2.4.10
>> - while having scheduled transactions with the "except on weekends" field set to non-standard
>> Knowing Murphy, obviously there will be someone entering that combination of conditions. :)
> Any "Save as" in 2.4.10 from a 2.4.11 database, regardless of backend, will drop the weekly_adjust value stored in the 2.4.11 database -- and of course the weekly_adjust won't work in 2.4.10, either, because it wasn't read.
Yes, that makes sense. Thanks for correcting me.


More information about the gnucash-devel mailing list