Board index » delphi » Cached Updates do not work anymore.

Cached Updates do not work anymore.

Has anyone else experienced the problem of using cached updates for a
master/detail type relationship within a database transaction.

If not, the problem is that if a database error occurs while inserting or
updating the detail record (via the dataset.applyupdates method), the db
transaction will get rolled back, which is good. However, the major problem
is that once you re-apply the updates, the master table will not be
re-applied. It basically looks like the cache was cleared, depsite that the
database.commitupdates was never executed.

Although this strategy for using cached updates (which we use for our order
entry systems) is clearly documented in the Delphi manuals, Borland support
is now saying that it is a "bug" in the documentation.

Personally, after being a huge Borland supporter for many years (~12), and
convincing many of our clients to go with Borland/Inprise as opposed to
Microsoft, I am actually re-considering. I even sent support a sample
application using the DBDEMOS database to proove the error.

Heck, I figured they would have been e{*word*277}d about a dedicated user finding,
re-creating, and isolating a bug. Guess I was wrong, instead they would just
rather write if off as a documentation bug.

As you can probably tell, this has been very disturbing to our entire
development team, and worse yet, our clients who we convinced to use Delphi
and the cache updates architecture.

If anyone has any way to contact Borland, other than the normal support
department, your help would be greatly appreciated.

The basic example that no longer works as listed on page 25-6 of the
developers guide is as follows:

Database1.StartTransaction;
try
  Master.ApplyUpdates;
  Detail.ApplyUpdates;
  Database1.Commit;
except
  Database1.Rollback
  raise;
end;
Master.CommitUpdates;
Detail.CommitUpdates;

Notice, if an error occurs on the Detail.ApplyUpdates; an exception will be
raised so the commitupdates does not fire. Somehow, the next time through,
the ApplyUpdates function does not re-apply the previous updates.

Support is also recommending that we use Midas instead of the traditional
two-tier application. Does anyone know if this is actually fixed within
Midas?

 

Re:Cached Updates do not work anymore.


It is not a bug.
It is supposed to work that way.
When applying updates, applied records must be marked as applied, otherwise
if you reapplied an insert, the record would be inserted twice. The cache
does not know whether applied records were committed or rolled back or still
in pending transaction.
Probably all BDE replacements work the same.

One thing would be usefull for this case: UnapplyUpdates method, which would
mark all applied as unapplied.

You can tweak this with OnUpdateRecord method for master:
<execute Updatesql.Apply> to apply the update:
UpdateAction := uaSkip; // won't mark it as applied

Naturally, after successfull commit you have to refresh dataset, as cache
contains invalid data - applied and committed records marked as unapplied.

--
----------------------
Regards
Robert Cerny
Remove both qwe when replying
email: robert.qwe.ce...@neosys.xrs.qwe.si

No questions via email, unless explicitly invited.

Re:Cached Updates do not work anymore.


Thanks for some ideas.

Once updates are applied via the dataset.applyupdates method and the
database commits successfully, we call the dataset.commitupdates, which
would clearthe cache. This would prevent any records from being inserted
twice.
In any case, I will try the UnApplyUpdates. Thanks!

Re:Cached Updates do not work anymore.


Try the following code and see if it makes any difference.  I was trying to
simulate your problem and this code works for me:

procedure TFMain.mBtCommitClick(Sender: TObject);
begin
  mDatabase.startTransaction;
  try
    // process details
    if (mQyDetail.state = dsInsert) or (mQyDetail.state = dsEdit) then
      mQyDetail.post;

    if mQyDetail.updatesPending then
      mQyDetail.applyUpdates;

    // process master
    if (mQyMaster.state = dsInsert) or (mQyMaster.state = dsEdit) then
      mQyMaster.post;

    if mQyMaster.updatesPending then
      mQyMaster.applyUpdates;

    mDatabase.commit;
  except
    mDatabase.rollback;
    raise;
  end;
  mQyDetail.commitUpdates;
  mQyMaster.commitUpdates;
end;

Brett

Quote
"Tim Peterson" <timpeter...@uty.com> wrote in message news:38e3cf65@dnews...
> Has anyone else experienced the problem of using cached updates for a
> master/detail type relationship within a database transaction.

> If not, the problem is that if a database error occurs while inserting or
> updating the detail record (via the dataset.applyupdates method), the db
> transaction will get rolled back, which is good. However, the major problem
> is that once you re-apply the updates, the master table will not be
> re-applied. It basically looks like the cache was cleared, depsite that the
> database.commitupdates was never executed.

> Although this strategy for using cached updates (which we use for our order
> entry systems) is clearly documented in the Delphi manuals, Borland support
> is now saying that it is a "bug" in the documentation.

> Personally, after being a huge Borland supporter for many years (~12), and
> convincing many of our clients to go with Borland/Inprise as opposed to
> Microsoft, I am actually re-considering. I even sent support a sample
> application using the DBDEMOS database to proove the error.

> Heck, I figured they would have been e{*word*277}d about a dedicated user finding,
> re-creating, and isolating a bug. Guess I was wrong, instead they would just
> rather write if off as a documentation bug.

> As you can probably tell, this has been very disturbing to our entire
> development team, and worse yet, our clients who we convinced to use Delphi
> and the cache updates architecture.

> If anyone has any way to contact Borland, other than the normal support
> department, your help would be greatly appreciated.

> The basic example that no longer works as listed on page 25-6 of the
> developers guide is as follows:

> Database1.StartTransaction;
> try
>   Master.ApplyUpdates;
>   Detail.ApplyUpdates;
>   Database1.Commit;
> except
>   Database1.Rollback
>   raise;
> end;
> Master.CommitUpdates;
> Detail.CommitUpdates;

> Notice, if an error occurs on the Detail.ApplyUpdates; an exception will be
> raised so the commitupdates does not fire. Somehow, the next time through,
> the ApplyUpdates function does not re-apply the previous updates.

> Support is also recommending that we use Midas instead of the traditional
> two-tier application. Does anyone know if this is actually fixed within
> Midas?

Re:Cached Updates do not work anymore.


Hey, there's no UnApplyUpdates!
I wrote that this method would be usefull for this case (aka wish list), but
it does not exist.
Try my other suggestion.

--
----------------------
Regards
Robert Cerny
Remove both qwe when replying
email: robert.qwe.ce...@neosys.xrs.qwe.si

No questions via email, unless explicitly invited.

Quote
Tim Peterson wrote in message <38e56b5d@dnews>...
>Thanks for some ideas.

>Once updates are applied via the dataset.applyupdates method and the
>database commits successfully, we call the dataset.commitupdates, which
>would clearthe cache. This would prevent any records from being inserted
>twice.

>In any case, I will try the UnApplyUpdates. Thanks!

Re:Cached Updates do not work anymore.


If I'm not mistaken, calling a Rollback clears your cache.  That's most
likely why there's a set of record-by-record error reconciliation routines
to avoid having to call back the entire set of updates.  The help files
aren't terribly clear here - one example actually says a rollback won't do
anything to your cache, but if you follow the TDatabase.Rollback method, it
says that this call clears your updates.  I'd bet on the latter.

My feeling says it's about 99% probable that you've got an error in your
logic flow, not that cached updates suddenly "broke."  It has worked for a
lot of people, and it didn't just 'break' on the release of D5.  Borland
support may not be able to recognize the error - cached updates are hard to
master, and although there are some really good folks there, unless you've
hit one that ought to be out consulting you probably have someone who just
wouldn't know to look at it.

Later -

  T

Quote
"Tim Peterson" <timpeter...@uty.com> wrote in message news:38e3cf65@dnews...
> Has anyone else experienced the problem of using cached updates for a
> master/detail type relationship within a database transaction.

> If not, the problem is that if a database error occurs while inserting or
> updating the detail record (via the dataset.applyupdates method), the db
> transaction will get rolled back, which is good. However, the major
problem
> is that once you re-apply the updates, the master table will not be
> re-applied. It basically looks like the cache was cleared, depsite that
the
> database.commitupdates was never executed.

> Although this strategy for using cached updates (which we use for our
order
> entry systems) is clearly documented in the Delphi manuals, Borland
support
> is now saying that it is a "bug" in the documentation.

> Personally, after being a huge Borland supporter for many years (~12), and
> convincing many of our clients to go with Borland/Inprise as opposed to
> Microsoft, I am actually re-considering. I even sent support a sample
> application using the DBDEMOS database to proove the error.

> Heck, I figured they would have been e{*word*277}d about a dedicated user
finding,
> re-creating, and isolating a bug. Guess I was wrong, instead they would
just
> rather write if off as a documentation bug.

> As you can probably tell, this has been very disturbing to our entire
> development team, and worse yet, our clients who we convinced to use
Delphi
> and the cache updates architecture.

> If anyone has any way to contact Borland, other than the normal support
> department, your help would be greatly appreciated.

> The basic example that no longer works as listed on page 25-6 of the
> developers guide is as follows:

> Database1.StartTransaction;
> try
>   Master.ApplyUpdates;
>   Detail.ApplyUpdates;
>   Database1.Commit;
> except
>   Database1.Rollback
>   raise;
> end;
> Master.CommitUpdates;
> Detail.CommitUpdates;

> Notice, if an error occurs on the Detail.ApplyUpdates; an exception will
be
> raised so the commitupdates does not fire. Somehow, the next time through,
> the ApplyUpdates function does not re-apply the previous updates.

> Support is also recommending that we use Midas instead of the traditional
> two-tier application. Does anyone know if this is actually fixed within
> Midas?

Re:Cached Updates do not work anymore.


Hi there,

Quote
"Thomas J. Theobald" wrote:
> If I'm not mistaken, calling a Rollback clears your cache.  That's most
> likely why there's a set of record-by-record error reconciliation routines
> to avoid having to call back the entire set of updates.  The help files
> aren't terribly clear here - one example actually says a rollback won't do
> anything to your cache, but if you follow the TDatabase.Rollback method, it
> says that this call clears your updates.  I'd bet on the latter.

Rollback clears uncommitted modifications on the database but leaves your cache
alone. This two buffers are independent. Rollback "happen" on the server while
the cache is local on the client. Use RevertRecord to restore just one row or
use CancelUpdates to clear your local cache.

Regards

Max

Quote

> My feeling says it's about 99% probable that you've got an error in your
> logic flow, not that cached updates suddenly "broke."  It has worked for a
> lot of people, and it didn't just 'break' on the release of D5.  Borland
> support may not be able to recognize the error - cached updates are hard to
> master, and although there are some really good folks there, unless you've
> hit one that ought to be out consulting you probably have someone who just
> wouldn't know to look at it.

> Later -

>   T

> "Tim Peterson" <timpeter...@uty.com> wrote in message news:38e3cf65@dnews...
> > Has anyone else experienced the problem of using cached updates for a
> > master/detail type relationship within a database transaction.

> > If not, the problem is that if a database error occurs while inserting or
> > updating the detail record (via the dataset.applyupdates method), the db
> > transaction will get rolled back, which is good. However, the major
> problem
> > is that once you re-apply the updates, the master table will not be
> > re-applied. It basically looks like the cache was cleared, depsite that
> the
> > database.commitupdates was never executed.

> > Although this strategy for using cached updates (which we use for our
> order
> > entry systems) is clearly documented in the Delphi manuals, Borland
> support
> > is now saying that it is a "bug" in the documentation.

> > Personally, after being a huge Borland supporter for many years (~12), and
> > convincing many of our clients to go with Borland/Inprise as opposed to
> > Microsoft, I am actually re-considering. I even sent support a sample
> > application using the DBDEMOS database to proove the error.

> > Heck, I figured they would have been e{*word*277}d about a dedicated user
> finding,
> > re-creating, and isolating a bug. Guess I was wrong, instead they would
> just
> > rather write if off as a documentation bug.

> > As you can probably tell, this has been very disturbing to our entire
> > development team, and worse yet, our clients who we convinced to use
> Delphi
> > and the cache updates architecture.

> > If anyone has any way to contact Borland, other than the normal support
> > department, your help would be greatly appreciated.

> > The basic example that no longer works as listed on page 25-6 of the
> > developers guide is as follows:

> > Database1.StartTransaction;
> > try
> >   Master.ApplyUpdates;
> >   Detail.ApplyUpdates;
> >   Database1.Commit;
> > except
> >   Database1.Rollback
> >   raise;
> > end;
> > Master.CommitUpdates;
> > Detail.CommitUpdates;

> > Notice, if an error occurs on the Detail.ApplyUpdates; an exception will
> be
> > raised so the commitupdates does not fire. Somehow, the next time through,
> > the ApplyUpdates function does not re-apply the previous updates.

> > Support is also recommending that we use Midas instead of the traditional
> > two-tier application. Does anyone know if this is actually fixed within
> > Midas?

--
MBS Software Co., Ltd.
67/359 Mooban Tantong 5
Tambon Vichit, Amphur Muang
Phuket 83000, Thailand

Tel: +66 76 242 516, Fax: +66 76 242 383
http://www.mbs-software.com, e-mail: m...@mbs-software.com

Other Threads