At 07:41 AM 22/06/2004 -0700, you wrote:

> > On 22-Jun-2004 00:27:06, Tim Ledgerwood wrote:
> > So - in my experience, IB/FB requires NO dba. At absolute worst, it
> > requires that I (once in a very long while indeed) provide remote
> > telephonic support. It is powerful, simple, and easy to use. I think that
> > some of the argument is based on the reasoning "it's a server DB, and
> > therefore requires a DBA because server DBs require DBAs"
>
>Tim, thanks for posting this. To me, this is priceless information. I was
>also concerned when I read Dmitry (sp?) reply on this,

You were right to be at least stirred by Dmitry's comments. The original
reference was to a downloadable shareware that was to be distributed
"blind" to "idiot users" - not to something like Tim's application which
goes out to known users and has support at the end of a phone line.

My point - which was bent around by a few knights on white horses - is that
"idiot users" don't know about things like backups; they also tend to
blast any old thing onto their computers and break things; they download
free SQL tools and stuff up databases...you get accountants who write cute
little Access front-ends that can break things *really* bad...

In a controlled deployment - where there's SOMEONE who knows about these
things - the DBA role can be very hands-off, once the users and the
knowledgeable person assigned the role of "boss of the system" (they
usually call themselves "the DBA", whatever their background) have been
coached into living with a database server.

I have seen too many sick or dead databases (and really rotten
applications) in my all-too-long life, that were the result of the kind of
laissez-faire that some of these white knights have been telling you
about. Oh, and not just InterBase databases, but MSSQL (especially!!) and
even one illegal Oracle site that was running under an evaluation licence
(until the day the licence expired, natch!).

>because I am
>converting an application that was written in a proprietary relational
>database management system over to Delphi/Firebird and the previous
>application never required a DBA to run it. I have worked on sites with
>various different SQL engines installed, and normally if an application is
>written correctly, it shouldn't require a DBA for any task other than
>monitoring that the backups are done correctly and regularly. For the most
>part, this can be scripted anyway. At least I'm speaking from a Vertical
>Market Application perspective where tech support/DBA requirements eat
>directly into the profitability of the application in the marketplace.

I'll tell you another thing that really chews up "the profitability of the
application in the marketplace" - the database going down from neglect of
housekeeping and/or any of the other stuff I mentioned - and being in a
severe down-time situation because either no backups were ever done, or
backups were never tested. If it happens to be a medical application (two
warzones I've had to clean up after fled developers, in recent years) then
profitability is fairly far down the disaster list.

There is *theory* and there is *practice*. Firebird stands apart from
MSSQL, Oracle, PostGreSQL and MySQL, because you don't have to HIRE a DBA
and install a bed in his/her office. It really is genuinely possible to
"watch" a 24/7 Firebird system from a great distance and with relative
irregularity - as long as you do the homework and are prepared to sleep
with your mobile under your pillow. It suits self-employed developers
very, very well. But, no, absolute blind faith is not a good formula for
deploying a database server and associated applications, even with Firebird.

It's a good thing to weigh the hyperbole against the realities of user
behaviour. I remember one place I worked, where we had a big sign on the
wall of the test lab: "If it wasn't for users, our software would be
perfect."

/heLen