postgres support and missing $ amounts in account detail

[Matthew Vanecek]

--=-0pRXXjzysSwYDi+x6hBo
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

This doesn't seem to personal, so I'm cc'ing gnucash-devel...

On Sat, 2002-11-23 at 09:43, cbbrowne@acm.org wrote:
> On 23 Nov 2002 08:38:03 CST, the world broke into rejoicing as
> Matthew Vanecek <mevanecek@yahoo.com>  said:
> > likely to be another 1.6.x release).  The CVS SQL backend has been
> > redesigned from 1.6.8, and I am in the process of redesigning the CVS
> > SQL backend. ;)  However, the CVS SQL backend is functional (albeit a
> > bit slow, depending on your setup--my DB is on a different machine, so
> > the network may be a bottleneck...).  I think we've ironned out the
> > major bugs.  This is the backend that will be released with 1.8.0,
> > coming sometime in December.  There's actually a time-line message on
> > this list, if you look through the archives.  It was posted on
> > Wednesday.
>=20
> This begs a "compatibility" question; will it be necessary to save
> as XML on an older version before loading, as XML, into the newer
> version?

No.  Current version of XML works fine.  Open up XML file, save as SQL
backend.  The two really don't have a whole lot to do with each other,
and technically, the data could be formatted completely different from
one backend to another, as long as the backend returns to the engine the
appropriate format.  I'm actually planning on something like that--what
makes sense in XML is often totally insane in SQL.

The problem with the 1.6.x SQL backend is not in the save, but in the
retrieve.  The Splits query is munged, and so the data doesn't show up
in the register.  The data, however, is fine when you check it in the
backend.

> Or will there be an SQL script to "clean things up?"
>=20

There will, of course, be a clear and somewhat transparent upgrade of
the SQL backend from one version to the next (somewhat transparent,
because the user *should* be made aware of what's going on).  Coupling
that with an administrator password would be optimal, in a multi-user
environment.  However, that still has no effect on the XML backend--you
can save to XML from SQL, or to SQL from XML, without having to worry
about clean-up scripts, etc, because it will always save using the
current version, and backends are required to pass data to the engine in
a set format.

> Make sure that is made /very/ clear; it would not do to get stranded
> with data in the wrong form!
--=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...

--=-0pRXXjzysSwYDi+x6hBo
Content-Type: application/DEFANGED-31; name="signature_asc.DEFANGED-31"

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

iD8DBQA937P9OMmiB1jXEBsRAqvBAKCDcxAdUp9RCD8rykmWQn88aHJqIACdHbeZ
QPYaFiEEqxmUswZTsr000r4=
=1pAH
-----END PGP SIGNATURE-----

--=-0pRXXjzysSwYDi+x6hBo--