On Saturday 08 January 2005 7:02 pm, Derek Atkins wrote: > Quoting Neil Williams <[EMAIL PROTECTED]>: > > > So what happens if you try to merge a QofBook that has an SX? > > > > Like any other object that isn't currently accessible by QOF, it is > > untouched. > > If the target book has SX, it is not altered, if the import book has SX, > > they > > > > are not merged. > > Except an SX uses Accounts and Transactions to store the templates... > Which means you WILL see SX "Accounts" in the data file if there are SXs in > the import book.
Noted. There are no SX's in the import or target book I used during testing, so something else in the group handling after the merge must be generating the error in the subaccount list when trying to save a QofBook after a merge. The qof_book_merge code has been committed to QOF CVS, if you want to see it as it stands after the static merge context was replaced. http://cvs.sourceforge.net/viewcvs.py/qof/qof/qof/qof_book_merge.c Or would you prefer a patch for GnuCash so that you can see the problem for yourself? The backtraces that I see only ever refer to 384: num_acc = g_list_length (grp->accounts); in src/engine/Group.c -- Neil Williams ============= http://www.dclug.org.uk/ http://www.nosoftwarepatents.com/ http://sourceforge.net/projects/isbnsearch/ http://www.williamsleesmill.me.uk/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
pgpJd4F4S60Pq.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
