Re: MS Access 'equiv' for Linux?

From: prg (rdgentry1_at_cablelynx.com)
Date: 04/06/05 

Date: 6 Apr 2005 13:49:22 -0700

Christopher Browne wrote:
> After a long battle with technology, "prg" <rdgentry1@cablelynx.com>,
an earthling, wrote:
> > Michael Heiming wrote:
> >> In comp.os.linux.misc John-Paul Stewart
<jpstewart@binaryfoundry.ca>:
> >> > John Hasler wrote:
> >> >> John-Paul Stewart writes:
> >> [..]
> >>
> >> >>>I can't imagine that there are very many Open Source developers
> > who would
> >> >>>sit down and write some software that they'd never use
themselves,
> > just
> >> >>>to satisfy some perceived demand.
> >> >>
> >> >>
> >> >> I've done just that several times, though nothing of any size.
So
> > have
> >> >> other Debian developers.
> >>
> >> > Again, I don't dispute that things like that do happen for
smaller
> >> > projects. But a project as large as an Access replacement is a
> >> > different story, IMHO.
> >>
> >> Which makes me wonder, as the question for M$ Access is showing
> >> up regular, has anyone tested one or more out of the shown apps:
> >
> > Sorta depends on what you mean by "test". I'm not aware of any
> > head-to-head comparisons nor much real publisizing of these apps.
> >
> >> 1) KNoda.
> >
> > Been around for a number years and has been considered for KDE
> > inclusion on occassion, IIRC. See below for "query designer" hot
air;)
> >
> >> 2) Gnome DB Manager.
> >
> > Not looked at this one too much as they seem to wanting to find a
> > "better way" to do point-n-click "programming". Query designer
crap
> > follows below.
>
> What bits I have used have been flakey :-(.
>
> >> 3) OpenOffice + MySQL.
> >
> > Google will provide a lifetime supply of howtos. I'm not a MySQL
fan
> > except for high volume, read intensive apps built around predefined
> > queries (aka, paramaterized queries).
>
> OpenOffice.org + PostgeSQL is similarly a sort of option; I find the
> OpenOffice.org front end to be pretty fragile as far as what it copes
> with well.
>
> >> 6) Berkley DB.
> >
> > Not appropriate in this context, IMHO. A "niche" (and a very good
one)
> > db design especially suited for lightweight, embedded applications.
>
> Quite inappropriate, indeed. It's a Really Powerful hash table
> implementation (with the option of using btrees); useful for some
> things, but not in general.
>
> >> 7) Rekall. [Prop]
> >
> > A gui "frontend" for db access. Another TheKompany offering.
> > Also open source/GPL:
> > http://www.rekall.a-i-s.co.uk/
> > Mostly backend/db connectivity issues
>
> This is NOT a "TheKompany" offering; it happens to be something that
> TheKompany resold for a while. I got a note from one of the authors
> indicating they were pretty irritated with TheKompany...
>

Thanks for the reminder/correction. IIRC, there was some little
bitterness over this issue. From what I've read, this is not uncommon
when folks take GPL/OSS software and "extend" it with pay-for-use
forks/packaging.

> >> 8) StarOffice Adabase.
> >
> > I think this is pretty much dead/legacy at this point. Adabase and
> > SAP (now offered by MySQL) have suffered from lack of adequate
> > (especially English) documentation. Feature set is pretty
> > impressive, but like all dbs, they have their peculiarities which
> > _must_ be documented to make full use:(
> >
> > SAP may finally provide the MySQL guys with "real" relational db
> > capabilities.
>
> Any integration with StarOffice would be about equivalent to what
> you'd get with PostgeSQL+OpenOffice.org
>
> And I don't see the move of Adabas-D (which was only one of Software
> AG's products; they still sell Adabas!), renamed to SAP-DB, now sold
> by MySQL AB as MaxDB(tm) to be an indication of continuing or
> forthcoming success for it. The codebase for SAP-DB was really quite
> painful to look at let alone work with. I cannot imagine that MySQL
> AB will be able to get anything meaningful out of it to integrate
with
> their products. All I can see happening in the short term is for
> there to be enough cash flow from supporting SAP-DB and MaxDB(tm)
> licenses for them to keep enough developers on staff to keep it from
> going totally moribund.
>
> And the only value I can see to the MySQL/SAP-DB deal is if the
> support involvement gives MySQL AB a vehicle to figure out what are
> the minimal capabilities that they can add to MySQL(tm) in order to
> make it into a reasonable host for some Adabas-D/SAP-DB applications,
> probably most notably SAP R/3. In the case of R/3, there _isn't_
that
> much that would need to be added, as it traditionally makes minimal
> use of anything more than the most primitive of "relational" database
> features...
>
> "Success" would be defined as making MySQL(tm) sufficiently
functional
> that they could get SAP AG to use them as a bludgeon in the next
round
> of gory negotiations between SAP AG and Oracle Corporation.
>
> (FYI: The above is the only reasonable scenario that has fallen out
of
> considerable puzzling over the way MaxDB(tm) has fallen to MySQL.)
>
> Aside from that possibility (which would be exceedingly messy, and
> would point to the free software community being a mere stepping
stone
> for all parties involved), I just can't see the use for the Adabas-D
> code at MySQL AB...
> --

Agree completely. Better summary/details than I could come up with in
such a succinct package. Can I quote you?

I have the same questions re: MaxDB and the folks at MySQL as well as
the further development of SAPdb by SAP for their ERP/CRM solutions.
Why take yourself off the $10,000,000 table for the Fortune 500 because
they aren't that interested in yet-another-db-backend?

It _will_ be interesting to see just what comes of the many recent db
"donations" to GPL. Still, it's an _awfull_ lot of work just getting
familiar with the code. And cross-breeding ???

Have not used PostgeSQL that much, but seems it's coming along rather
well. Their appearance on Windows has stirred notice/interest at
Firebird re: how to provide UDF "extensions" for backend code. Good to
have others out there that keep you on your toes.

regards,
prg

Relevant Pages

  • Re: Datenbank SQL-Server vs. MySQL
    ... > OK to argue against mySQL is easy, you always can argue of missing ... SAP DB is ADABAS D. Software AG was failing and decided to exit the ... in the database business and started to look for ways to keep SAP DB going ... industrial strength you have to use the InnoDB storage engine. ...
    (microsoft.public.de.german.entwickler.dotnet.datenbank)
  • Re: MS Access equiv for Linux?
    ... >> support involvement gives MySQL AB a vehicle to figure out what are ... >> the next round of gory negotiations between SAP AG and Oracle ... Better summary/details than I could come up with ... And cross-breeding ??? ...
    (comp.os.linux.misc)
  • Re: MS Access equiv for Linux?
    ... I'm not a MySQL fan ... And I don't see the move of Adabas-D (which was only one of Software ... they still sell Adabas!), renamed to SAP-DB, now sold ... probably most notably SAP R/3. ...
    (comp.os.linux.misc)
  • Re: Non GPL Python MySQL Client Library.
    ... > worlds 3rd largest Software Company SAP. ... that MySQL AB essentially took over development of SAP DB (MaxDB by ... preferring to stick to a core business of supporting ...
    (comp.lang.python)
  • Re: MySQL JDBC driver - implications for non-GPLed apps
    ... as I've never tried to submit a patch to MySQL. ... > received patches from open-source developers. ... Developers that produce closed source themselves get a stable fast ... If you are sued, it will cost you money, even if the other party comes ...
    (comp.lang.java.databases)