Re: MS Access 'equiv' for Linux?
From: Christopher Browne (cbbrowne_at_acm.org)
Date: 04/06/05
- Next message: Tony Hwang: "Re: How to tell if CF card is faulty?"
- Previous message: poorstudent: "Re: Getting rid of XP"
- In reply to: prg: "Re: MS Access 'equiv' for Linux?"
- Next in thread: prg: "Re: MS Access 'equiv' for Linux?"
- Reply: prg: "Re: MS Access 'equiv' for Linux?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 06 Apr 2005 01:35:23 GMT
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...
>> 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...
-- (format nil "~S@~S" "cbbrowne" "gmail.com") http://linuxdatabases.info/info/slony.html "A ROUGH WHIMPER OF INSANITY" is an anagram for "INFORMATION SUPERHIGHWAY".
- Next message: Tony Hwang: "Re: How to tell if CF card is faulty?"
- Previous message: poorstudent: "Re: Getting rid of XP"
- In reply to: prg: "Re: MS Access 'equiv' for Linux?"
- Next in thread: prg: "Re: MS Access 'equiv' for Linux?"
- Reply: prg: "Re: MS Access 'equiv' for Linux?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
