Help with libdbi code

John Ralls jralls at ceridwen.us
Sat May 7 07:01:48 EDT 2016


> On May 7, 2016, at 6:22 AM, Colin Law <clanlaw at gmail.com> wrote:
> 
> On 7 May 2016 at 10:09, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
>> ...
>> I'm not sure you need to do this when connecting to the mysql database (not
>> table) and before creating the new database. At that point there is no data
>> in the new database so there can't be any NULL in a date field either.
>> 
>> On the other hand it may be that you do have to do this if MySQL already
>> complains when writing the DB schema which I consider unlikely (yet not
>> impossible).
> 
> I believe that it is necessary as the initial problem is encountered
> when creating the database as one of the date fields has a default
> value of zero.  In fact I have not found a case where the no_zero_date
> option causes a problem other than when creating a new database, but I
> have not tried very hard.  I had wondered whether an alternative
> strategy of not providing a default value, but allowing the date to be
> null in the database instead was possible, but I gather that would
> involve significant work.  In addition it would cause problems when
> upgrading gnucash as old databases would no longer be compatible.

Hmm, the trace files from the bug report seemed to show that the error was from saving a slot row with a 0-valued date rather than from creating a table with a default value of 0.

The only issue with schema changes is that they make the database incompatible between GnuCash versions. I agree that it's dumb to declare a date field NOT_NULL and then store 0 in it. It was also my (apparently mis-)understanding that NO_ZERO_DATE also meant no NULL dates. If that's not the case and we can work around the schema change issue (easy if it really is just during DB creation) then that's a better way to address the problem.

Regards,
John Ralls




More information about the gnucash-devel mailing list