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