This doesn't seem to personal, so I'm cc'ing gnucash-devel... On Sat, 2002-11-23 at 09:43, [EMAIL PROTECTED] wrote: > On 23 Nov 2002 08:38:03 CST, the world broke into rejoicing as > Matthew Vanecek <[EMAIL PROTECTED]> 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. > > 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?" > 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! -- Matthew Vanecek perl -e 'print $i=pack(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...
signature_asc_DEFANGED-31.DEFANGED-518046
Description: application/defanged-518046
