Saving with new mysql 5.7 triggers in db

Derek Atkins derek at ihtfp.com
Mon May 15 12:38:32 EDT 2017


   Hi,
   On May 15, 2017 12:20 PM, John Ralls <jralls at ceridwen.fremont.ca.us>
   wrote:

   On May 15, 2017, at 8:49 AM, Derek Atkins <[1]warlord at mit.edu> wrote:

   Geert Janssens <[2]geert.gnucash at kobaltwit.be> writes:

     Is it possible that GnuCash just isn't being happy with the
     "modified"
     tables?

     Possibly and that's what John also suggests. I don't know the exact
     details of
     how the sql backend interacts with the tables. I just know there are
     ways in
     general that you can have extra columns in an sql table than there
     are columns
     used in an insert/update query. When columns are omitted they are
     normally set
     to their default value on insert or ignored on an update. I used
     that idea to
     suggest my alternative trigger.
     On the other hand if the sql backend for some reason sets
     restrictions on the
     available columns this may be an issue. Only a real test can tell
     but I'm not
     interested enough right now to spend the effort. On the other hand
     if someone
     else is, I would appreciate to hear the result.
     And John's other remark was even more to the point. Why not use the
     year(),
     month() and day() function directly in the queries instead of
     duplicating the
     info in the table ?

   I haven't looked at the code but inserts can be done implicitly or
   explicitly.  If they are done implicitly then any change to the table
   could cause problems on future inserts.  I don't know if GnuCash uses
   implicit or explicit insertions.

   If "implicit" means "whole record with fields in order and not tagged
   with field names" that's what GnuCash does.

   Yes, that is what I mean..

   Regards,
   John Ralls

   -derek

References

   1. mailto:warlord at mit.edu
   2. mailto:geert.gnucash at kobaltwit.be


More information about the gnucash-devel mailing list