Subject | RE: [IBO] IBO speed vs BDE? |
---|---|
Author | Claudio Valderrama C. |
Post date | 2001-04-20T04:51:57Z |
> -----Original Message-----When you learn about transactions, you will discover that a typical BDE
> From: Chuck Belanger [mailto:phytotech@...]
> Sent: MiƩrcoles 18 de Abril de 2001 4:44
>
> But, again my question. how much difference does it make having the BDE
> between my program and Interbase and direct access to IB via IBO?
> Is it worth
> a re-write to include these?
application attaches all data-aware datasets to one TDatabase component
that's at the same time the transaction control object. So, when you commit,
all datasets are affected, whether they are related to the data being
committed or not (In this context, "affected" may mean closed or refetched).
IB allows several concurrent transactions in one connection and IBO gives
you an easy way to follow this model. So, if you have 10 forms and each one
uses its own transaction because it's a separate unit of work, in IBO your
commit only deals with the datasets in that form. On the other side, if you
really want to create a BDE-equivalent app, you can attach all IBO datasets
to only one transaction. Not being forced to refetch all datasets after a
transaction ends is one feature that makes your app faster with IBO, among
others. You can read about IBO features on my site at www.cvalde.com if you
like.
Ah, but don't fix what doesn't need to be fixed. If your app is perfectly
happy with FoxPro and you don't need transactions and more reliability,
maybe you're just fine with Fox. It seems that many engines use now some
kind of bitmapped structure to handle multiple conditions in a search; IB
had that capability since its first days.
C.