Subject | Re: [IBDI] about IBO |
---|---|
Author | Helen Borrie |
Post date | 2002-04-16T08:33:49Z |
At 09:29 AM 16-04-02 +0200, Jordi wrote:
two. The ones with TIBO* prefix are data acess only - a TIBODatabase, a
TIBTransaction, a TIBOTable, a TIBOQuery, a TIBOStoredProcedure and a
TIBOUpdateSQL. That's it. They work with Delphi's TDatasource and all of
the VCL components.
The other suite is what Jason refers to as "native IBO". It consists of
about 80 components including both data access and controls. It isn't
compatible with the TIBO* data access comps or controls - except that you
*can* use the native data access comps in TIBO* applications for executable
SQL or, in the case of the TIB_Cursor component, as a quick way to bring a
non-visible output set into your application - IF YOU WANT TO.
Nobody has to take the native stuff if they only want to do similar to what
one would do with the BDE, IBX, etc. (You only pay a subscription for IBO
if you are getting paid for your work...and the subscription for the
TDataset connectivity is not much at all.)
If someone comes from the BDE world, there are five details that are
different about the TDataset-compatible data access:
1. Applications connect to databases with a network string instead of a
BDE alias.
2. In queries and tables alike, you have to define Keylinks which, in the
simple case means you have to include your primary key as a property (which
the component will do automatically if you tell it to); with joined output
sets, it means listing all of the columns that make up a unique key for the
dataset.
3. Any query output set (even joins and unions) can be live.
4. You can use custom SQL for any dataset's insert, update and delete
methods without having to use a clientdataset.
5. Your apps have to connect explicitly to the database and they have to
open datasets explicitly - which they can do all at once, like the BDE, or
as required, which is preferable for client/server.
Of course, you get some optional extra capabilities from the
InternalDataset wrapper and also through the extra capabilities of IBO's
connection component; and you can have multiple transactions if you want
them; but things don't have to be any different from the BDE - you will
get your BDE app up and running without doing anything but search and
replace in your DFMs.
cheers,
Helen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________
>Jason,It already exists! IBO in fact is not one suite of components, but
>
>wouldn't be interesting to make an "IBO light-weight edition" (or something
>similar) with just the few basic connection components, quick and easy
>installation and low learning curve?
two. The ones with TIBO* prefix are data acess only - a TIBODatabase, a
TIBTransaction, a TIBOTable, a TIBOQuery, a TIBOStoredProcedure and a
TIBOUpdateSQL. That's it. They work with Delphi's TDatasource and all of
the VCL components.
The other suite is what Jason refers to as "native IBO". It consists of
about 80 components including both data access and controls. It isn't
compatible with the TIBO* data access comps or controls - except that you
*can* use the native data access comps in TIBO* applications for executable
SQL or, in the case of the TIB_Cursor component, as a quick way to bring a
non-visible output set into your application - IF YOU WANT TO.
Nobody has to take the native stuff if they only want to do similar to what
one would do with the BDE, IBX, etc. (You only pay a subscription for IBO
if you are getting paid for your work...and the subscription for the
TDataset connectivity is not much at all.)
If someone comes from the BDE world, there are five details that are
different about the TDataset-compatible data access:
1. Applications connect to databases with a network string instead of a
BDE alias.
2. In queries and tables alike, you have to define Keylinks which, in the
simple case means you have to include your primary key as a property (which
the component will do automatically if you tell it to); with joined output
sets, it means listing all of the columns that make up a unique key for the
dataset.
3. Any query output set (even joins and unions) can be live.
4. You can use custom SQL for any dataset's insert, update and delete
methods without having to use a clientdataset.
5. Your apps have to connect explicitly to the database and they have to
open datasets explicitly - which they can do all at once, like the BDE, or
as required, which is preferable for client/server.
Of course, you get some optional extra capabilities from the
InternalDataset wrapper and also through the extra capabilities of IBO's
connection component; and you can have multiple transactions if you want
them; but things don't have to be any different from the BDE - you will
get your BDE app up and running without doing anything but search and
replace in your DFMs.
cheers,
Helen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________