Board index » delphi » To cache or not to cache updates ?

To cache or not to cache updates ?

In his Cached Update Example, Jeff Overcash uses CachedUpdate queries in
order to update selects back to IB.
And I read everywhere, and in IB doc itself, that indeed, CachedUpdate
brings the ability to edit and update records within a set that otherwise
would stay static.

But lets look to a different way of doing it:
When I just add an IBUpdateSQL, put in the SQL statements and relate it to
the IBQuery, but _with CachedUpdate to false_, well, all this above happens
: the datas get updated as expected.

- So, do I have to consider that it is IBUpdateSQL that brings update
capabilities -and not caching ?

- In the case you tell me that it is better to cache, how to handle this
with Master/Detail tables ?

For instance, in the case of insertion, the Master must be updated before
the Detail.
On the other hand, on deletion, it is the reverse: the Detail table must
receive deletes before the Master.

- Does the IBX components take this in account, or do I have to do some
workaround ?

(BTW, there is an example in the Developer's Guide, Chapter "Working with
Cached Updates", "Applying updates for master/detail tables". When I run
it, I get an error on the first statement "IBTransaction1.StartTransaction;"
: the transaction is already open. Yes indeed, it is open by the
IBTansaction.
So should I just skip this line ?
Plus, in order not to restart the transaction, should I emit a
CommitRetaining ?
This might make things go quicker from one each user point of view.
But does'nt this have a negative impact on performance, when too many users
hold on a transaction on IB ?)

--
Henri Cesbron

 

Re:To cache or not to cache updates ?


Quote
Henri Cesbon Lavau wrote:

> In his Cached Update Example, Jeff Overcash uses CachedUpdate queries in
> order to update selects back to IB.
> And I read everywhere, and in IB doc itself, that indeed, CachedUpdate
> brings the ability to edit and update records within a set that otherwise
> would stay static.

> But lets look to a different way of doing it:
> When I just add an IBUpdateSQL, put in the SQL statements and relate it to
> the IBQuery, but _with CachedUpdate to false_, well, all this above happens
> : the datas get updated as expected.

> - So, do I have to consider that it is IBUpdateSQL that brings update
> capabilities -and not caching ?

Yes, it is the IBUpdate that does this.  TIBQuery is a Read-Only dataset.  The
IBUpdateSQL tells it how to update the underlying SQL of the TIBQuery.  It is
not necessary to go into cached update to accomplish this.

Quote

> - In the case you tell me that it is better to cache, how to handle this
> with Master/Detail tables ?

Because of a flaw in IBX's caching scheme, I recommend against cached updates in
m-d situations.  Use straight transaction control here or if you have enterprise
use ClientDataSets (I always recommend CDS over Cached Updates if you have Ent).

Quote
> For instance, in the case of insertion, the Master must be updated before
> the Detail.
> On the other hand, on deletion, it is the reverse: the Detail table must
> receive deletes before the Master.

> - Does the IBX components take this in account, or do I have to do some
> workaround ?

> (BTW, there is an example in the Developer's Guide, Chapter "Working with
> Cached Updates", "Applying updates for master/detail tables". When I run
> it, I get an error on the first statement "IBTransaction1.StartTransaction;"
> : the transaction is already open. Yes indeed, it is open by the
> IBTansaction.
> So should I just skip this line ?

Yes skip it.  The BDE does a lot of local caching allowing it to disconnect from
the transaction.

Quote
> Plus, in order not to restart the transaction, should I emit a
> CommitRetaining ?

That is the only way to accomplish this.

Quote
> This might make things go quicker from one each user point of view.
> But does'nt this have a negative impact on performance, when too many users
> hold on a transaction on IB ?)

It can if you are automatically sweeping the database.  A lot depends on how
much garbage can collect over time in your DB.

Quote
> --
> Henri Cesbron

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
Mild mannered supermen are held in kryptonite, and the wise and foolish
{*word*269}s giggle with their bodies glowing bright.  Through the door a harvest
feast is lit by candlelight; it's the bottom of the staircase that spirals out
of sight.
  (new classic Genesis) Carpet Crawlers 1999

Re:To cache or not to cache updates ?


Question in line:

Jeff Overcash (TeamB) a crit dans le message
<39C23385.7B283...@onramp.net>...

Quote
>Because of a flaw in IBX's caching scheme, I recommend against cached
updates in
>m-d situations.  Use straight transaction control here or if you have
enterprise
>use ClientDataSets (I always recommend CDS over Cached Updates if you have
Ent).

I've not been yet to Midas, although I have D5 enterprise.
For I'm looking first to test IB on a standalone basis.
I thought using IBX would run quicker.

- If I go Midas and CDS, will I be able to develop the multi-tier model on a
single computer ?

Some of my smallest clients will still use it on a standalone computer.
I would like to have the same programming scheme for these one as for those
with a network.

- Will MIDAS allow to do it ?

All of this running with Interbase.
I choose Interbase for all my applications, also because of the
professionnal support
I get from this list and especially from you. Thanks.

Henri

Quote
>--
>Jeff Overcash (TeamB)
>      (Please do not email me directly unless  asked. Thank You)
>Mild mannered supermen are held in kryptonite, and the wise and foolish
>{*word*269}s giggle with their bodies glowing bright.  Through the door a
harvest
>feast is lit by candlelight; it's the bottom of the staircase that spirals
out
>of sight.
>  (new classic Genesis) Carpet Crawlers 1999

Re:To cache or not to cache updates ?


Quote
Henri Cesbon Lavau wrote:

> Question in line:

> Jeff Overcash (TeamB) a crit dans le message
> <39C23385.7B283...@onramp.net>...
> >Because of a flaw in IBX's caching scheme, I recommend against cached
> updates in
> >m-d situations.  Use straight transaction control here or if you have
> enterprise
> >use ClientDataSets (I always recommend CDS over Cached Updates if you have
> Ent).

> I've not been yet to Midas, although I have D5 enterprise.
> For I'm looking first to test IB on a standalone basis.
> I thought using IBX would run quicker.

You just have much better resolution control with ClientDatasets than with
Cached Updates.

Quote
> - If I go Midas and CDS, will I be able to develop the multi-tier model on a
> single computer ?

Yes.

Quote
> Some of my smallest clients will still use it on a standalone computer.
> I would like to have the same programming scheme for these one as for those
> with a network.

> - Will MIDAS allow to do it ?

Yes you can.  A lot of people use MIDAS in 1 and two tier situations and not
just n-tier.

Quote
> All of this running with Interbase.
> I choose Interbase for all my applications, also because of the
> professionnal support
> I get from this list and especially from you. Thanks.

Dan Miser probably gives better support for MIDAS on the midas groups than I do
here, so adding ClientDataSets won't hurt in that respect.  There is an article
by Dan at http://community.borland.com/article/print/0,1772,20567,00.html on how
to easily replace cached updates with ClientDatasets.

Quote
> Henri

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
Mild mannered supermen are held in kryptonite, and the wise and foolish
{*word*269}s giggle with their bodies glowing bright.  Through the door a harvest
feast is lit by candlelight; it's the bottom of the staircase that spirals out
of sight.
  (new classic Genesis) Carpet Crawlers 1999

Re:To cache or not to cache updates ?


Quote
Jeff Overcash (TeamB) wrote in message <39C23385.7B283...@onramp.net>...

......
Quote
>It can if you are automatically sweeping the database.  A lot depends on
how
>much garbage can collect over time in your DB.

......

Q:

How do I automatically sweep a database?
What happens when you are (or are not) sweeping a database?

Re:To cache or not to cache updates ?


Quote
Daniel Tytens wrote:

> Jeff Overcash (TeamB) wrote in message <39C23385.7B283...@onramp.net>...

> ......
> >It can if you are automatically sweeping the database.  A lot depends on
> how
> >much garbage can collect over time in your DB.
> ......

> Q:

> How do I automatically sweep a database?

By default IB sweeps every 20000 transactions.  You can turn that off or set it
to a different value.

Quote
> What happens when you are (or are not) sweeping a database?

More garbage is left in the database so pages are less full of real data causing
more page reads to read the same amount of data.

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
Mild mannered supermen are held in kryptonite, and the wise and foolish
{*word*269}s giggle with their bodies glowing bright.  Through the door a harvest
feast is lit by candlelight; it's the bottom of the staircase that spirals out
of sight.
  (new classic Genesis) Carpet Crawlers 1999

Re:To cache or not to cache updates ?


Quote
Daniel Tytens wrote:

> How do I automatically sweep a database?

        Set the sweep interval with gfix.  This should explain it further for
you:

http://www.ibphoenix.com/doc0260.html

Quote
> What happens when you are (or are not) sweeping a database?

        If the DB is not being swept, (regular) performance will go downhill.
While the sweep is running, there will be a temporary performance drop.
If you are doing backups and restores regularly enough, sweeping will
not be necessary.  Automatic sweeps cannot occur while you have
transactions in limbo.

        HTH,

        -Craig

--
Craig Stuntz            Vertex Systems Corporation
Senior Developer        http://www.vertexsoftware.com

Re:To cache or not to cache updates ?


Thank you for answering.
Things are getting clear.

Other Threads