Subject | Re: [IBO] Mixing navive and "TDataset compatable" controls? |
---|---|
Author | Jason Wharton |
Post date | 2002-04-18T18:12:14Z |
There are three primary ways to have a connection and transaction in your
application.
TIB_Connection and TIB_Transaction are the two fundamental classes being
dealt with.
All statement, dataset, transaction, etc. components are built to work with
connections and transactions at this level. This means even if you are using
a TDataset based TIBOQuery you can hook it up to a raw TIB_Connection
instead of the more suited TIBODatabase component if you want to.
Beyond these there is a TIB_Database component which takes a sub-class of
the TIB_Connection component and ties inside of it a TIB_Transaction
instance and surfaces the transaction's stuff along with the other
connection stuff. Thus, the whole thing is wadded together in one component.
The internal transaction instance has defaults a little different, like
AutoCommit being true. It is setup as the DefaultTransaction of its owning
connection and if another transaction is attempted to be assigned to this
property there will be an exception preventing it. But, there is nothing
stopping you from having a dataset hooked to the TIB_Database and then its
transaction explicitly set to another "on its own" transaction component. A
TIBxDatabase component or a connection with a DefaultTransaction assigned
only is used by a statement or dataset if there isn't one assigned to it.
(This is as opposed to the statement or dataset creating its own internal
transaction instance when there isn't any other default transaction
mechanism in place.)
TIBODatabase is a sub-class of TIB_Database and it simply adds in some
features and functionality that make it more useful when doing a conversion
from a BDE based application to IBO, e.g. it will still read information
from a BDE alias (without using any BDE dll's) and do some cached updates
stuff recognizing the TIBODataset class strain instead of the TIB_Dataset
class strain that is otherwise assumed.
I also added in the TIBOTransaction component so that richer transaction
control could be accomplished with the TDataset based module of IBO. This
allows multiple concurrent transaction contexts for a single connection
using the TDataset based components.
Which brings to mind another reason why there are three connection
components. I now have three core modules that you only need one of to use
most of the other stuff in the whole IBO suite of components. Each of these
core modules needs a connection component of some kind.
Hope this helps clear things up a little bit.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
application.
TIB_Connection and TIB_Transaction are the two fundamental classes being
dealt with.
All statement, dataset, transaction, etc. components are built to work with
connections and transactions at this level. This means even if you are using
a TDataset based TIBOQuery you can hook it up to a raw TIB_Connection
instead of the more suited TIBODatabase component if you want to.
Beyond these there is a TIB_Database component which takes a sub-class of
the TIB_Connection component and ties inside of it a TIB_Transaction
instance and surfaces the transaction's stuff along with the other
connection stuff. Thus, the whole thing is wadded together in one component.
The internal transaction instance has defaults a little different, like
AutoCommit being true. It is setup as the DefaultTransaction of its owning
connection and if another transaction is attempted to be assigned to this
property there will be an exception preventing it. But, there is nothing
stopping you from having a dataset hooked to the TIB_Database and then its
transaction explicitly set to another "on its own" transaction component. A
TIBxDatabase component or a connection with a DefaultTransaction assigned
only is used by a statement or dataset if there isn't one assigned to it.
(This is as opposed to the statement or dataset creating its own internal
transaction instance when there isn't any other default transaction
mechanism in place.)
TIBODatabase is a sub-class of TIB_Database and it simply adds in some
features and functionality that make it more useful when doing a conversion
from a BDE based application to IBO, e.g. it will still read information
from a BDE alias (without using any BDE dll's) and do some cached updates
stuff recognizing the TIBODataset class strain instead of the TIB_Dataset
class strain that is otherwise assumed.
I also added in the TIBOTransaction component so that richer transaction
control could be accomplished with the TDataset based module of IBO. This
allows multiple concurrent transaction contexts for a single connection
using the TDataset based components.
Which brings to mind another reason why there are three connection
components. I now have three core modules that you only need one of to use
most of the other stuff in the whole IBO suite of components. Each of these
core modules needs a connection component of some kind.
Hope this helps clear things up a little bit.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com