CVS GnuCash fails on assertion in postgres backend

Matthew Vanecek mevanecek@yahoo.com
22 Sep 2002 11:15:17 -0500


--=-1psJS3jelv5ymoRwf6Y1
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2002-09-22 at 09:34, Derek Atkins wrote:
> As I've said a number of times (but I'll repeat myself), it is quite
> likely that the postgres backend has bitrotted in CVS.  I can
> certainly tell you 100% that it will not work for Scheduled
> Transactions or Business Accounting purposes.
>=20
> Having said that....
>=20
> Matthew Vanecek <mevanecek@yahoo.com> writes:
>=20
> > Info: sqlQuery_build: term is QUERYCORE_GUID
> > 	Info: sqlQuery_build: GUID param is      book
> > 	Info: sqlQuery_build: GUID next param is guid
> > 	Info: sqlQuery_build: GUID options is    1
> > Info: sqlQuery_build: Unknown GUID parameter, book
>=20
> This warning corresponds to this code:
>=20
> 	     PINFO ("Unknown GUID parameter, %s", (char*)path->data);
>=20
> 	     /* XXX: Need to support the Book GUID? (gncAccount.bookGUID) */
>=20
> It probably needs to get supported, but frankly I don't know what to
> test for.  Hopefully during the postgres re-write this will get fixed.
>=20
> > Info: sqlQuery_build: term is QUERYCORE_GUID
> > 	Info: sqlQuery_build: GUID param is      account
> > 	Info: sqlQuery_build: GUID next param is guid
> > 	Info: sqlQuery_build: GUID options is    1
> >=20
> > ** ERROR **: file gncquery.c: line 897 (sqlQuery_build): assertion
> > failed: (pdata->options !=3D GUID_MATCH_ANY)
> > aborting...
> > Aborted (core dumped)
>=20
> Interesting.  pdata->options _is_ GUID_MATCH_ANY, which is perfectly
> legal...
>=20
> > The above line number should be 890 in the CVS-original source.  I
> > haven't tracked down what pdata->options is *supposed* to be at this
> > point (i.e., point being loading Splits/Transactions/Whatever from the
> > backend to put into the Register).  Any suggestions on how to proceed
> > would be a benefit.  Is there a particular reason pdata->options is not
> > supposed to be GUID_MATCH_ANY here?
>=20
> Ahh.. I see the problem.  This was a braino on my part when converting
> to the new query type.  The fix: change all four assertions for
> "GUID_MATCH_ANY" to "GUID_MATCH_ALL" in that section of code.  I was
> testing against the wrong option type.  Sorry.  I've fixed this in
> CVS.
>=20
> -derek
>=20

There probably won't be another release of 1.6.x, right?  Is there a
site that patches can be posted to for this type of fix?

--=20
Matthew Vanecek
perl -e 'print
$i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
***************************************************************************=
*****
For 93 million miles, there is nothing between the sun and my shadow
except me.
I'm always getting in the way of something...

--=-1psJS3jelv5ymoRwf6Y1
Content-Type: application/DEFANGED-7; name="signature_asc.DEFANGED-7"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9jeyVOMmiB1jXEBsRAg0NAKCc/Z5kyUd4uL0FZV0d8S9aGUIq1gCfbFJv
EaM9V8peHK5HomX/XJ2PhpI=
=WA9U
-----END PGP SIGNATURE-----

--=-1psJS3jelv5ymoRwf6Y1--