Board index » delphi » Bug in Cached updates and Transactions in BDE

Bug in Cached updates and Transactions in BDE

This is not a bug. It's wrong way of thinking. If updates rolled back, it
means that they are still pending, so you can correct the problem and retry
or cancel updates:

Database1.StartTransaction;
try
    if Query1.UpdatesPending then
        Query1.ApplyUpdates;
    if Query1.UpdatesPending then
        Query2.ApplyUpdates;
    Database1.Commit;
    Query1.CommitUpdates;  // this was missing
    Query2.CommitUpdates;
    // now, no updates are pending anymore
except
    if <somereason> then Query1.CancelUpdates;
    Database1.RollBack;
    Raise;
end;

Until you commit updates, they are still pending.
However, when I tested BDE alternatives, I found that ADO has problems with
this, if you have server side cursor (maybe I did something wrong), so, if
it doesn't work for you as described, either it's the bug in client library
or you do something wrong.
--
----------------------
Regards
Robert Cerny
Remove both qwe when replying
email: robert.qwe.ce...@neosys.xrs.qwe.si

No questions via email, unless explicitly invited.

Quote
Robert Milmine wrote in message <88k94j$q...@bornews.borland.com>...
>What's happening is if you run the code bellow and query2 get's an
>error Query1 looses it's UpdatesPending.  Which means when it
>rollsback the changes for Query1 don't get on the server but the
>client thinks they have.  If you have datacontrols connected to it
>you will even see the data looks like it's been updated but it hasn't

>Does any one know of a workaround for the following bug?  Other
>than putting a transaction around each query that is.

>Database1.StartTransaction;
>try
>    if Query1.UpdatesPending then
>        Query1.ApplyUpdates;
>    if Query1.UpdatesPending then
>        Query2.ApplyUpdates;
>    Database1.Commit;
>except
>    Database1.RollBack;
>    Raise;
>end;

>Thanks,
>Robert Milmine
>The Princeton Review.

 

Re:Bug in Cached updates and Transactions in BDE


Quote
"Robert Cerny" <robert.qwe.ce...@neosys.xrs.qwe.si> wrote:
>except
>    if <somereason> then Query1.CancelUpdates;
>    Database1.RollBack;
>    Raise;
>end;

CancelUpdates will delete all changes made to the cache since the last
Open or successful update. I think Robert Milmine meant to keep the
changes and be allowed to try another update. Instead, this will
delete all his changes if I read the documentation correctly.

Phil Cain
--

Re:Bug in Cached updates and Transactions in BDE


Quote
Philip Cain wrote in message ...
>"Robert Cerny" <robert.qwe.ce...@neosys.xrs.qwe.si> wrote:

>>except
>>    if <somereason> then Query1.CancelUpdates;
>>    Database1.RollBack;
>>    Raise;
>>end;

>CancelUpdates will delete all changes made to the cache since the last
>Open or successful update. I think Robert Milmine meant to keep the
>changes and be allowed to try another update. Instead, this will
>delete all his changes if I read the documentation correctly.

>Phil Cain
>--

Completely true. That's why I wrote "if <there is some reason to do it> then
cancelupdates"

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

No questions via email, unless explicitly invited.

Re:Bug in Cached updates and Transactions in BDE


I still have the problem were the client does the ApplyUpdates and get's an
error
it then goes into the except code and rolls back the transaction.  What this
means
is that the first query ends up thinking that it has sent it's changes but
in reallity it hasn't as they were rolled back.  How do I let it know that
the changes that it sent to the server were rolled back and it needs to send
them again?

Robert Milmine
The Princeton Review

Quote
"Robert Cerny" <robert.qwe.ce...@neosys.xrs.qwe.si> wrote in message

news:8942j7.1j8.0@neosys.xrs.si...
Quote
> Philip Cain wrote in message ...
> >"Robert Cerny" <robert.qwe.ce...@neosys.xrs.qwe.si> wrote:

> >>except
> >>    if <somereason> then Query1.CancelUpdates;
> >>    Database1.RollBack;
> >>    Raise;
> >>end;

> >CancelUpdates will delete all changes made to the cache since the last
> >Open or successful update. I think Robert Milmine meant to keep the
> >changes and be allowed to try another update. Instead, this will
> >delete all his changes if I read the documentation correctly.

> >Phil Cain
> >--

> Completely true. That's why I wrote "if <there is some reason to do it>
then
> cancelupdates"

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

> No questions via email, unless explicitly invited.

Re:Bug in Cached updates and Transactions in BDE


See my first answer.
"Updates pending" has nothing to do with transactions, it's just a status of
record in cache.
So, if you call "CommitUpdates", for all pending updates it just deletes old
values from cache and clears the pending flag.

The best solution is to call TDatabase.ApplyUpdates(..). If you want
something additional, copy the code from there and it will work.

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

No questions via email, unless explicitly invited.

Quote
Robert Milmine wrote in message <893voc$9...@bornews.borland.com>...
>I still have the problem were the client does the ApplyUpdates and get's an
>error
>it then goes into the except code and rolls back the transaction.  What
this
>means
>is that the first query ends up thinking that it has sent it's changes but
>in reallity it hasn't as they were rolled back.  How do I let it know that
>the changes that it sent to the server were rolled back and it needs to
send
>them again?

Re:Bug in Cached updates and Transactions in BDE


I understand that but for some reason I'm getting it clearing the cache like
I had called "CommitUpdates" when I haven't.  This is what I'm having a
problem with the cache is getting cleared when all I've called is
"ApplyUpdates".

Robert Milmine

Quote
"Robert Cerny" <robert.qwe.ce...@neosys.xrs.qwe.si> wrote in message

news:8954c5.1pa.0@neosys.xrs.si...
Quote
> See my first answer.
> "Updates pending" has nothing to do with transactions, it's just a status
of
> record in cache.
> So, if you call "CommitUpdates", for all pending updates it just deletes
old
> values from cache and clears the pending flag.

> The best solution is to call TDatabase.ApplyUpdates(..). If you want
> something additional, copy the code from there and it will work.

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

Re:Bug in Cached updates and Transactions in BDE


Well, ok. whatever. You insist on suffering from bug. Go ahead. If you took
a closer look at your code, you'd allready find it, I can't neither want to
do it for you. The purpose of help in newgroups is to provide guidelines
that help you solve the problem and not to give you complete solutions. I
pointed out one bug in your code, still you insist on doing everythink ok.
Bah.

You might have another event (like OnScroll) that cancels or commits
updates.

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

No questions via email, unless explicitly invited.

Quote
Robert Milmine wrote in message <89e8sr$h...@bornews.borland.com>...
>I understand that but for some reason I'm getting it clearing the cache
like
>I had called "CommitUpdates" when I haven't.  This is what I'm having a
>problem with the cache is getting cleared when all I've called is
>"ApplyUpdates".

>Robert Milmine

Re:Bug in Cached updates and Transactions in BDE


This isn't a bug in my code as I've been able to get several people to
verify that this is happening.
Take the code that you wrote and try it.
Make a change in both queries and have the one in query2 cause an exception
so that the
database rollsback.
Then fix the error and rerun the code.
What you are going to find happens is that the first queries data never gets
to the server as it was rolledback
and the query was never informed of the rollback.

Robert Milmine
The Princeton Review

Quote
"Robert Cerny" <robert.qwe.ce...@neosys.xrs.qwe.si> wrote in message

news:89hh6h.3jt.0@neosys.xrs.si...
Quote
> Well, ok. whatever. You insist on suffering from bug. Go ahead. If you
took
> a closer look at your code, you'd allready find it, I can't neither want
to
> do it for you. The purpose of help in newgroups is to provide guidelines
> that help you solve the problem and not to give you complete solutions. I
> pointed out one bug in your code, still you insist on doing everythink ok.
> Bah.

> You might have another event (like OnScroll) that cancels or commits
> updates.

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

> No questions via email, unless explicitly invited.
> Robert Milmine wrote in message <89e8sr$h...@bornews.borland.com>...
> >I understand that but for some reason I'm getting it clearing the cache
> like
> >I had called "CommitUpdates" when I haven't.  This is what I'm having a
> >problem with the cache is getting cleared when all I've called is
> >"ApplyUpdates".

> >Robert Milmine

Re:Bug in Cached updates and Transactions in BDE


LOL.
I did and it works. That's the reason I wrote it here.

Do you use TUpdateSQL or apply updates in UpdateRecord event?
If you use UpdateRecord event and somehow update the record, set
UpdateAction=uaSkip,
this will leave "unapplied" record flag.
And read the help.

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

No questions via email, unless explicitly invited.

Quote
Robert Milmine wrote in message <8bdajs$b...@bornews.borland.com>...
>This isn't a bug in my code as I've been able to get several people to
>verify that this is happening.
>Take the code that you wrote and try it.
>Make a change in both queries and have the one in query2 cause an exception
>so that the
>database rollsback.
>Then fix the error and rerun the code.
>What you are going to find happens is that the first queries data never
gets
>to the server as it was rolledback
>and the query was never informed of the rollback.

>Robert Milmine
>The Princeton Review

Re:Bug in Cached updates and Transactions in BDE


I'm not using a TUpdateSQL I'm using a live query.

Robert Milmine.

Quote
"Robert Cerny" <robert.qwe.ce...@neosys.xrs.qwe.si> wrote in message

news:8be26h.112.0@neosys.xrs.si...
Quote
> LOL.
> I did and it works. That's the reason I wrote it here.

> Do you use TUpdateSQL or apply updates in UpdateRecord event?
> If you use UpdateRecord event and somehow update the record, set
> UpdateAction=uaSkip,
> this will leave "unapplied" record flag.
> And read the help.

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

> No questions via email, unless explicitly invited.
> Robert Milmine wrote in message <8bdajs$b...@bornews.borland.com>...
> >This isn't a bug in my code as I've been able to get several people to
> >verify that this is happening.
> >Take the code that you wrote and try it.
> >Make a change in both queries and have the one in query2 cause an
exception
> >so that the
> >database rollsback.
> >Then fix the error and rerun the code.
> >What you are going to find happens is that the first queries data never
> gets
> >to the server as it was rolledback
> >and the query was never informed of the rollback.

> >Robert Milmine
> >The Princeton Review

Re:Bug in Cached updates and Transactions in BDE


I have tried this with Live Queries and with a TUpdateSQL and I get the same
error
with both.  If there is a way to tell the query that it skipped the record
with TUpdateSQL then
I missed it.  I do understand the idea of using the skip unfortunately I
inherited this project and
it has way to many queries in it to change in this way.  If this is the only
way to get around this
bug then I guess I will have to at some point.  But this is still only a
work around to an actual
bug.

Robert Milmine
The Princeton Review

Quote
"Robert Milmine" <Rober...@Review.com> wrote in message

news:8bg1gb$6gc2@bornews.borland.com...
Quote
> I'm not using a TUpdateSQL I'm using a live query.

> Robert Milmine.

> "Robert Cerny" <robert.qwe.ce...@neosys.xrs.qwe.si> wrote in message
> news:8be26h.112.0@neosys.xrs.si...
> > LOL.
> > I did and it works. That's the reason I wrote it here.

> > Do you use TUpdateSQL or apply updates in UpdateRecord event?
> > If you use UpdateRecord event and somehow update the record, set
> > UpdateAction=uaSkip,
> > this will leave "unapplied" record flag.
> > And read the help.

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

> > No questions via email, unless explicitly invited.
> > Robert Milmine wrote in message <8bdajs$b...@bornews.borland.com>...
> > >This isn't a bug in my code as I've been able to get several people to
> > >verify that this is happening.
> > >Take the code that you wrote and try it.
> > >Make a change in both queries and have the one in query2 cause an
> exception
> > >so that the
> > >database rollsback.
> > >Then fix the error and rerun the code.
> > >What you are going to find happens is that the first queries data never
> > gets
> > >to the server as it was rolledback
> > >and the query was never informed of the rollback.

> > >Robert Milmine
> > >The Princeton Review

Re:Bug in Cached updates and Transactions in BDE


Another workaround would be to check all data before post, so that server
accepts the whole transaction, but note that this is even more work, since
you transfer part of server logic to client. It has some side effects:
- less network traffic (good)
- you generally less use backend specific features (good-portable)
- client side logic tends to be spread throughout application (or many
applications) (bad-maintainance nightmare), with server side logic you can
change business rules independent from application.

Use whichever suggestion you want. I prefer the first because of last
mentioned side effect of this workaround. I'm not aware of any "easy" one.
--
----------------------
Regards
Robert Cerny
Remove both qwe when replying
email: robert.qwe.ce...@neosys.xrs.qwe.si

No questions via email, unless explicitly invited.

Quote
Robert Milmine wrote in message <8cd1it$5...@bornews.borland.com>...
>I have tried this with Live Queries and with a TUpdateSQL and I get the
same
>error
>with both.  If there is a way to tell the query that it skipped the record
>with TUpdateSQL then
>I missed it.  I do understand the idea of using the skip unfortunately I
>inherited this project and
>it has way to many queries in it to change in this way.  If this is the
only
>way to get around this
>bug then I guess I will have to at some point.  But this is still only a
>work around to an actual
>bug.

Other Threads