On Tue, 09 Nov 1999 14:54:55 PST, the world broke into rejoicing as
"jools enticknap" <[EMAIL PROTECTED]> said:
> Hi Chris
>
> >On Mon, 08 Nov 1999 09:41:03 PST, the world broke into rejoicing as
> >"jools enticknap" <[EMAIL PROTECTED]> said:
> > > I've had a look through the mail archives, but I could'nt find and any
> >words
> > > written about a possible Java port.
> > >
> > > I've been using Xacc for ages and I like it, and I wanted to attach it
> >to a
> > > MySQL database by modifying the engine, but I thought it would most
> >likey be
> > > easier to start a Java port and use JDBC.
> > >
> > > If there is a project (not gnucash) already doing something like this
> >would
> > > they kindly let me know!
> >
> >This "project description" is tantamount to a complete reimplmentation from
> >scratch.
>
> I have'nt described any projects yet, it was simply a suggestion/request for
> feed back.
>
> >Looking back into the examinations ancient past, there is *not* that
> >much merit to putting in an SQL database; that mandates getting into
> >DBA issues, which makes it considerably more complex to deploy the system.
>
> Perhaps. I'm not saying that the Java version should be SQL only.
>
> I'm just saying that it makes writting reports easier, and a little more
> flexible.
Somewhat arguable, in both directions.
GnuCash doesn't have a terribly rich data model, which limits the complexity
that there is at present in writing reports.
Once you jump to an SQL model, you can certainly create more sophisticated
reports, but this comes at the cost of the increased complexity of having
to "do SQL."
It's not an unalloyed benefit.
> In once sence I do agree, trying to get a DBA to allow access to
> databases it a little like getting blood from a stone.
Sometimes DBA's appear to be trained to be jerks; the *real* point is
that by going to something like MySQL or PostgreSQL, *someone* has to
be assigned the task of "being the DBA," as a DB instance needs to be set
up for use by the financial software.
The point is that it's not as simple as:
# rpm -i mysql-1.1.i386.rpm
or
# apt-get mysql
And "then it all works." It *doesn't* all work; you need to do some
DBA work to allow apps to access it.
> On the other hand take a look at, dare I say it .. Windows.
> If you install Office these days, using up more than 300Mb's of Hard disk
> space, you end up with an installation of Access. which is ODBC compilant
> and can be used via JDBC/ODBC bridge from Java. Without a DBA to bee seen
> anywhere.
At work, we make use of Access for some "departmental applications;"
the conclusion that I'm coming to is that its "embedded data store"
is not robust enough for anything more important than "not the faintest
bit important."
It might be reasonable to use Access as a front end onto another (vastly
more reliable) DBMS. Which is quite unfortunate, as the front end has
pretty diverse functionality. If they had a reliable embedded DB in it,
Access would be an example of a product that Microsoft bought that was
actually fairly useful.
But note that once you start using it as a "front end" to some other DBMS,
the DBA issue rears its ugly head again...
--
"Why use Windows, since there is a door?"
-- <[EMAIL PROTECTED]> Andre Fachat
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
