Cool, thanks for the response. Yea, my question really related to the
future of firebird. I have no problem with commitment as long as it's
reciprocated! :)

I guess really my concerns are about the future of Delphi, Firebird,
IBObjects - all the stuff I'm building my product (and hopes and dreams)
with!

In any case it's not really like I can do much about it if I found out some
of my tools where to be abandoned...You are right I've made my decision, I
guess the answer can only make me a bit more anxious about the future or put
me a bit at ease at this point. I'm hopeing for answers to put me a bit at
ease! :)

At any rate, I think you make good points. I would love to dig in and learn
a database really well and take advantage of it's power and make my program
a well oiled machine.


-----Original Message-----
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On Behalf
Of Dany M
Sent: Thursday, February 23, 2006 6:31 PM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] SQL Hourglass et. al.

Anthony Tanas wrote:

> Hello everybody,
>
> I'm new to IBObjects and to this list.
>

[snip]

> On the other hand if I move functionality to the server then I am going

to > be more tightly attached to firebird. Is this a good bet?

>

You are posting to the IBObjects list asking about IBO Components. The
component suite you are using is targeted on Firebird/Interbase. So, in a
way (depending on your other clients/environments, if any) you have already
made that choice.

Secondly, a little on FB history. FB comes from the Interbase open source
version that Borland/Inprise released. Shortly after this move Borland went
on with t commercial IB. FB/IB are still rather compatible but are steadily
"forking away" from each other. I write this in case you ment "tighty
attached to Firebird as opposed to Interbase" rather than "tightly attached
to Firebird as opposed to any other ANSI compliant SQL DB like MS SQL,
Oracle, MySQL and so on and so forth".

Sticking to one DB can be beneficial in the sense that the (usually and in
FBs case - vast) functionality of the server can be utilized fully.
Personally I was never a fan of switching between back ends and coding for
"the least common denominator" which is what has to be done if easy
switching between DBs are to be supported. This is of course a high level
decision and very often more political/economical/strategical that technical
(IMHO). If the users are to be the foremost benefactors (and not the
shareholders) then "can use any database" applications are "unsexy" and
laborious to maintain (IMHO - again). Ops, I'm transgressing from the
subject and I am getting into feelings rather than knowledge - so I stop
this here.

Then, practically you will *almost* always benefit from putting stuff into
the server. Foreign key constraints that you are mentioning is a quite basal
feature of a relational database and most brands can manage it. There might
be differences in how NULL values are handled, multiple field constraints
and so on.

Imagine the load over the network when you issue one SQL DELETE statemet for
each detail and then one for the master as opposed to issuing one delete
statement for the master (which would be the case if you where using
constraints). Also - what you have to do if there is an error in the middle
and a detail can not be deleted because you don't want to leave half a bill
dangling.

The concept of transactions (something that the BDE obscured) is another
*really* beneficial thing to read up about in the start.

HTH,

/Dany


___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Yahoo! Groups Links