> Adam wrote:
> > The simple act of comparing it with Access is actually part of the
> > problem.
> Nope, you misunderstand me. I wasn't COMPARING Firebird to Access, how
> can you?

OK, you were contrasting them (possibly unintentionally) by talking
about being 'cramped by Access'. These guys clearly haven't done
enough due dilligence in their research (or their executive summary
really lets them down). When they hear that Firebird is better than
Access, you have to remember that this is precisely what they expect
to hear from someone else in that space. Talking about software X as
being cramped or restricted is to them typical rhetoric from any open
source software.

What we need to do is show how Firebird was a better choice than SQL
Server for application X or why MySQL could not be used because it
lacked Y or how Oracle lacked any distinguishing feature for Z.

The truth is that if a particular DBMS was the best in all areas,
evolution would see the rest die out. They would more or less keep
their existing customer base for existing projects, but new projects
would be written using whatever the best was, and old projects would
be migrated if viable.

> I am talking about the low memory and disk resources MANY small
> businesses work with. That to me is a significant plus point for
> Firebird when talking to frightened clients - "Hey look, you don't have
> to upgrade your kit!"

I actually think this is the market Firebird wins quite easily. If a
company can not afford to spend a couple of hundred on a super fast
SCSI Raid and a tonne of RAM, they are hardly about to run off and buy
some Oracle seats or pay a DBA to baby sit it, nor spend thousands on
the best hardware.

They are more likely to choose some desktop database like Access or
Paradox or choose some 'free' one like MySQL, and then realise that
they must pay a license fee because it is commercial use.

The real competitors in this space for Firebird are PostgreSQL and
MSDE/SQL Server, and IMO the most serious threat would be PostgreSQL

> > Not that Firebird couldn't be used in place of an access
> > database, but anyone storing a significant amount of data wouldn't
> > even consider Access as an option.
> >
> Yeah, but in my experience they DO - until Access turns up its toes and
> they panic. An awful lot of people still equate change to high expense
> in small business, and are equally suspicious of what appears to be a
> free lunch. They'll grudgingly pay through the nose to Microsoft

because

> they don't trust or know anything about the alternatives.

But we are thinking about different people here, and the ones you
refer to are not the people who would pay $1000 for a 14 page report.
Any company that employs any person with the most remote knowledge of
databases would not attempt a multi-user database built on Access.

There will always be a preference of 'the devil you know' over the one
you don't.

>
> > ........The paper does well to list the sorts of
> > features that form a sensible common denominator
> >
> Wouldn't it be good to have a similar paper aimed at lay people,
> pointing up what's good for them in a less technical way? To me, that's
> where MySQL are scoring big time, they sell their product in

layman's terms.

The problem is that it is a very difficult thing to explain a 2 phase
commit or MGA or even referential integrity to someone who has no idea
about databases is a tall ask. Most of them expect to see some GUI
database building tool (and think that is what a database is).

This market is best attacked by a simple 'What on earth are you trying
to do that with Access for, you should consider Firebird'.

I think a testament to the success of the model is the number of fixes
and enhancements, compare the number in FB 1, in FB 1.5 and in FB 2.
(and not counting fixes to bugs introduced by these versions). Even
though these reports attack the credibility of the project by making
statements such as it lacks a driving company, you can see that there
is exponential growth in the development.

Adam