Board index » delphi » IBX and dBX

IBX and dBX


2004-07-14 11:18:41 PM
delphi194
I've been using IBX for some time now, but I am starting a new project
using Intraweb, and wondering if dBX might not be a better way to go.
I'm thinking it may be easier to change the back-end to something other
than Interbase if the DB support functions use dBX instead of IBX.
Any comments or pointers to discussion about this subject would be
appreciated.
TIA, Glynn
 
 

Re:IBX and dBX

Bill Todd (TeamB) writes:
Quote
The purpose of dbExpress is to allow you to easily change backends.
Unfortunately, like all multi-database driver layers it is a leas
common denominator approach in that it does not support many of the
unique features of each of the databases it supports.

In the case of InterBase dbExpress does not support many of the
transaction options, does not provide a way to create a database and
does not support any of the functionality provided by the IB Admin
components in IBX.


--
Bill (TeamB)
(TeamB cannot respond to questions received via email)
Thanks, Bill. I guess I will stick with what I know rather than get
bogged down trying to anticipate problems that may never crop up.
Regards, Glynn
 

Re:IBX and dBX

In addition to what Bill said, the 'S' in SQL does not stand for
standard, it stands for structured. Different server handle sql
differenlty and in my experience you end up having to tweek the sql
when you change databases....
hth
Ro
 

Re:IBX and dBX

"Glynn Owen" <XXXX@XXXXX.COM>writes:
Quote
Bill Todd (TeamB) writes:

>The purpose of dbExpress is to allow you to easily change backends.
>Unfortunately, like all multi-database driver layers it is a leas
>common denominator approach in that it does not support many of the
>unique features of each of the databases it supports.
>
>In the case of InterBase dbExpress does not support many of the
>transaction options, does not provide a way to create a database and
>does not support any of the functionality provided by the IB Admin
>components in IBX.
>
>
>--
>Bill (TeamB)
>(TeamB cannot respond to questions received via email)

Thanks, Bill. I guess I will stick with what I know rather than get
bogged down trying to anticipate problems that may never crop up.

Regards, Glynn
What I do is make certain all my DB access layer is isolated
in a data module with no direct access to the outside world.
Then if I need to switch out backends all I have to mess with
is say an Oracle equivalent of the IBX DM and change them out in the project. You still get the advanatage of working close
to the backend with a design that is flexible to switch from
IBX to say DOA.
 

Re:IBX and dBX

Jeff Overcash (TeamB) writes:
Quote
What I do is make certain all my DB access layer is isolated
in a data module with no direct access to the outside world.
Then if I need to switch out backends all I have to mess with
is say an Oracle equivalent of the IBX DM and change them out in the
project. You still get the advanatage of working close to the
backend with a design that is flexible to switch from IBX to say DOA.
Excellent advice. Thank you.
Glynn
 

Re:IBX and dBX

Robert Schieck (TeamB) writes:
Quote
In addition to what Bill said, the 'S' in SQL does not stand for
standard, it stands for structured. Different server handle sql
differenlty and in my experience you end up having to tweek the sql
when you change databases....

hth

Ro

I attempt to put often-used features into stored procedures in hopes
that it will be fairly easy to re-write those procedures for another
server.
Thanks for the thought,
Glynn
 

Re:IBX and dBX

Bill Todd (TeamB) writes:
Quote
On 15 Jul 2004 06:47:24 -0700, "Glynn Owen" <XXXX@XXXXX.COM>
writes:

>I attempt to put often-used features into stored procedures in hopes
>that it will be fairly easy to re-write those procedures for another
>server.

That is not likely to be the case. The procedure and trigger language
differs widely from one database server to the next.

--
Bill (TeamB)
(TeamB cannot respond to questions received via email)
Thanks for the heads-up.
Regards, Glynn