--- Lester Caine <lester@...> wrote:

> Am I the only person who is getting irritated by the
> criticism that
> Firebird is not very good as a single user built in
> database engine?

Lester,

I couldn't disagree more.

Yes, under some scenarios it is possible to log in remotely
into a PC to fix problems. Many time however it is not.
While working for a company which based its application on
Interbase, we devised a mechanism allowing the customer to
send us a problem gdb file at a click of a button, so we
could diagnose it in our offices.

It may surprise you, but some businesses (not to mention
private users) are still on 33.6 modems. I found it very
hard to work with databases over that kind of speed (or
lack thereof).

Under other scenarios, the IT manager will not even want to
discuss the possibility of opening port 3050. No amount of
convincing will do to change their mind. Take Ritz-Carlton
Chicago for example. They are using a hotel management
system based on IB. There is no way they will expose their
port 3050 to the outside world - too much sensitive info in
the database about quite a few celebrities. If Ritz-Carlton
need things fixed then a programmer is on its way to
Chicago on the next plane. Money is not object to them.
Security is. You mentioned security in the opening
sentences of your email so I felt I could address it.

OK, I got sidetracked here a little. The topic is FB
Embedded.

I have been selling a small (actually trivial) desktop
application since March 2003. It's used by an equally small
(about 150) niche of users. Written in Delphi and (of
course!) using Firebird Embedded. The database structure is
pretty simple (about 40 tables of varying complexity). Each
user adds between 200 to 5000 records daily. I appreciate
stored procedures, triggers and UDFs. My distributable
(including FB) is at 2.9MB. In well over a year not a
single user reported any problems that would even hint on
data corruption.

You might try to say I am basically using FB to do the same
job a flat text file could do for me, i.e. store data. I
hope you understand why you shouldn�t. Even with mere
thousands of records per table the advantages of using FB
instead of flat file are obvious.

As for the security, I use a little home made encryption
mechanism based on Blowfish algo. But even that only to
deal with fields containing meaningful string data such as
names, addresses etc. The speed penalty is minimal under
that scenario, and data security is sufficient. If someone
is determined to compromise that data security they will.
The only sure security scheme is to delete the data file,
melt the hard disk and then shred the remnants into
metallic powder. With todays technology it's a pretty good
security system, but who know what future holds :-)

I have the comfort of working with people who neither
consider getting hold of someone else's data, nor are even
remotely attractive for hackers.

Now the blasphemy part:
I'm not using the final version of FB Embedded, but rather
one of the RC versions. That way I have to add only under
800KB to my final distributable. This babe runs like a
charm. I couldn't ask for more.

Having said all that, I have to admit that before FB
Embedded surfaced, I was considering using of the full
server. At some 2.9MB as of now it�s still pretty damn
small to distribute as a part of an application.


my $0.02 (CDN)
I don�t even know why I wrote all this :-)






__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail