After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 165096 - GC 1.8.10 forgets HBCI <-> Account releationship when using SQL backend
GC 1.8.10 forgets HBCI <-> Account releationship when using SQL backend
Status: VERIFIED FIXED
Product: GnuCash
Classification: Other
Component: Backend - SQL
1.8.x
Other Linux
: Normal normal
: ---
Assigned To: Christian Stimming
Christian Stimming
Depends on:
Blocks:
 
 
Reported: 2005-01-24 14:35 UTC by Dirk Heinrichs
Modified: 2018-06-29 20:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dirk Heinrichs 2005-01-24 14:35:33 UTC
I've successfully setup HBCI online banking in GC 1.8.10. But when I close GC  
and restart it, I need to tell it again which HBCI account corresponds to which  
GC account.  
  
It doesn't happen if the file backend is used to store the data.
Comment 1 Derek Atkins 2005-01-24 22:55:51 UTC
I'm not at all surprised.  The SQL backend is broken in many ways; I'm not at
all shocked that it's broken in this way, too.
Comment 2 Christian Stimming 2005-01-25 08:46:52 UTC
Oops, so basically the HBCI functions are unusable with the SQL backend, and are
only working with the file backend? That's bad. 

Derek: This HBCI <-> account relationship is stored in the kvp-frame of the
account and it's quite simple (needs storing three particular strings, nothing
more). What would need to be done to enable the storing of this information in
the SQL backend? I vaguely recall some problems with kvp-frames and SQL... but
are the kvp-frames still encouraged or rather deprecated in favor of something else?
Comment 3 Derek Atkins 2005-02-23 15:44:31 UTC
Uh, kvps should work in SQL, but most likely you're hitting bug #87652 (or
something thereabouts).  You might need to do something like:

xaccAccountBeginEdit()
<modify kvp>
xaccAccountCommitEdit()

Even worse, you may need to "kick" the account in the <modify kvp> portion to
get the account itself marked "dirty" so it gets re-written to the database.

So, I think this is an HBCI bug, not a SQL bug.
Comment 4 Christian Stimming 2005-02-23 22:03:44 UTC
Actually the BeginEdit/CommitEdit is already being used in the kvp setting. So 
this obviously is not yet enough :-( 
Comment 5 Derek Atkins 2005-02-23 22:10:57 UTC
You might need to also do something like:

  QOF_INSTANCE(acct)->dirty = TRUE;

before the CommitEdit().  Are you making any other changes to the Account
between the begin/commit edit?

Oh, also, this change probably wont work in 1.8 as-is; you'll need something to
get the account marked dirty.
Comment 6 Christian Stimming 2005-02-25 11:22:34 UTC
How about something like

 xaccAccountSetSlots_nc(acct, xaccAccountGetSlots(acct));

That should work in both 1.8 and HEAD, I guess.
Comment 7 Derek Atkins 2005-02-25 13:45:21 UTC
Yea, that should work.
Comment 8 Christian Stimming 2005-02-26 11:07:54 UTC
Ok, committed. This means the bug is hopefully resolved in CVS, which will
become either a 1.8.12 or a 2.0.0 release.
Comment 9 John Ralls 2018-06-29 20:49:24 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=165096. Please update any external references or bookmarks.