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