Board index » delphi » Cached Update bugs...Anyone else found them?

Cached Update bugs...Anyone else found them?

I have lost confidence with Borland's Delphi Cached Updates.  I have
discovered a really annoying bug which exists in Delphi 3.02 and the
BDE when using cached updates.  Briefly the cache does not seem to
always get cleared after successful calls to ApplyUpdates.  What I
tend to find is one record - usually the last Insert seems to remain
in the cache.  SQL Monitor shows the cached updates are all valid and
have been applied OK, and no Update SQL exception has been raised.
Then when adding a whole new set of updates the first update is of
course the last insert that was successfully processed but not
cleared.  BANG! unique key violation when the insert tries to insert
again.  Calling CommitUpdates as a measure to clear the rogue insert
doesn't always work, and re opening the Dataset doesn't either.

Also there are problems if you have a master/detail dataset
configuration using cached updates.  Do an insert on the master, then
modify this record, in the meantime do some operations on the detail
dataset.  Apply the Master cached updates so that the detail has a
parent record for its cached update records.  Then try to apply the
detail updates and ???? nothing in the Detail cache.  If an update
occurs on the master dataset then detail dataset cache gets cleared.
Now that is really clever Borland.  So how the hell do you get around
that one?  Apply the cache after every insert on the master?  Defeats
the point of caching.

Also those damn annoying Paradox .MB files that Delphi uses to store
to cache don't always get cleared up.  After a while you have manually
purge them.

The rogue insert not being cleared from the cache is is a serious
issue but as usual probably won't be addressed by Borland/Inprise.  I
have found 3 or 4 major bugs in Delphi but if you try and report them
it's like
"Have you got a support contract"
"No..."
"Well you can't report the bug then, fill out the online bug report"
"But I have done before and you do nothing about it..."
"Well maybe it's not a bug then...."
"But after reporting it on the Newsgroups other people have verified
it as a bug."
"Erm well sorry that's all Borland/Inprise can offer you."

Whatever happened to customer service, I am forced to ask myself, is
that shit or what?

Paul Scott
Oi Delphi Development team... you {*word*30}wits have forgotten to call
inherited in the WMCommand message handler of TCustomGrid since Delphi
1.  So how do you process child controls' notifications if in
descendent classes of TCustomGrid controlstyle includes
csAcceptControls?

 

Re:Cached Update bugs...Anyone else found them?


Quote
In article <35e06005.18794...@news.tcp.co.uk>, aspsc...@tcp.co.uk (Paul) wrote:
>I have lost confidence with Borland's Delphi Cached Updates.  I have
>discovered a really annoying bug which exists in Delphi 3.02 and the
>BDE when using cached updates.  Briefly the cache does not seem to
>always get cleared after successful calls to ApplyUpdates.  What I
>tend to find is one record - usually the last Insert seems to remain
>in the cache.  SQL Monitor shows the cached updates are all valid and
>have been applied OK, and no Update SQL exception has been raised.
>Then when adding a whole new set of updates the first update is of
>course the last insert that was successfully processed but not
>cleared.  BANG! unique key violation when the insert tries to insert
>again.  Calling CommitUpdates as a measure to clear the rogue insert
>doesn't always work, and re opening the Dataset doesn't either.

I've been using cached updates quite a lot.  The only thing I've really found
with them is that they're "tricky" (and a *big* note - if you're trying
to use them in Delphi 4, make *sure* you get the patch).  Haven't run into the
cached update clearing problem you describe, though.  Might want to check
UpdatesPending to see if there's anything left to go.  Note that you
*should* call CommitUpdates after a successful ApplyUpdates regardless (you
can also call the TDatabase's ApplyUpdates... it will combine both
operations).

Quote
>Also there are problems if you have a master/detail dataset
>configuration using cached updates.  Do an insert on the master, then
>modify this record, in the meantime do some operations on the detail
>dataset.  Apply the Master cached updates so that the detail has a
>parent record for its cached update records.  Then try to apply the
>detail updates and ???? nothing in the Detail cache.  If an update
>occurs on the master dataset then detail dataset cache gets cleared.
>Now that is really clever Borland.  So how the hell do you get around
>that one?  Apply the cache after every insert on the master?  Defeats
>the point of caching.

If you're using TQuery objects with the cached updates, you basically just
have to be careful that your detail query doesn't get re-run while you have
updates pending.  My code does the master-detail itself (I needed multiple
masters, so I created TDataLink-based classes to observe the 1..n masters)...
I can't remember whether putting an ApplyUpdates in the OnDataChange does the
trick.  The TQuery goes and fetches the result subset (unlike a TTable, which
simply applies a "range" onto the entire dataset), and once it's re-run, the
cached updates don't have a corresponding record to hook on to (it's almost
like trying to expect a TBookmark to work after closing and opening a
dataset).

The cached updates weren't intended solely for network traffic reduction and
the like, though.  Its seeming primary use (and the one I'm most grateful for)
is to allow read-only SQL queries (and SQL will use almost any excuse to give
a read-only dataset...) to behave as though they were read/write.  Then, when
it needs to be written to the database, I can pop it through a few queries
that suit the purpose.

Quote
>Also those damn annoying Paradox .MB files that Delphi uses to store
>to cache don't always get cleared up.  After a while you have manually
>purge them.

I've found that the .MB files do actually disappear on program shutdown on cue
as long as no exiting exceptions are found.  Mine only hang around if the
program is running around on its last legs and decides to give an error 216
(an Access Violation after the named error handling has been unloaded).

Quote
>The rogue insert not being cleared from the cache is is a serious
>issue but as usual probably won't be addressed by Borland/Inprise.  I
>have found 3 or 4 major bugs in Delphi but if you try and report them
>it's like
>"Have you got a support contract"
>"No..."
>"Well you can't report the bug then, fill out the online bug report"
>"But I have done before and you do nothing about it..."
>"Well maybe it's not a bug then...."
>"But after reporting it on the Newsgroups other people have verified
>it as a bug."
>"Erm well sorry that's all Borland/Inprise can offer you."

When I wrote in about the D4 cached updates problem, I put the problem into
the shortest reproducible form I could, sent that along with a detailed
step-by-step, and reported the workarounds I tried that also didn't work.  
They got back to me fairly quickly on it, regretfully informing me that there
was no current workaround, but when the first D4 update came out, the fix was
the second one on the list (woohoo :)

Quote
>Whatever happened to customer service, I am forced to ask myself, is
>that shit or what?

*sigh* I do wonder.  I suppose it's some terrible compromise that is made
these days - where if you free-support one person who has a genuine problem,
you end up with 19 people asking for things it's really not Borland/Inprise's
mandate to provide solutions for.  How far before "I tried to make my window
have a size limit when resizing, but it's jerky - how do I do that?" do you
cut off what a user could be free-supported for?  Would they perhaps put
people on a points system, where they get a point for every genuine problem
they eke out, and lose/spend one for everything that isn't, and just support
people who keep their 'balances' on the positive side?

Is it that "programming has gotten easier" that started to deluge them with
calls from neophytes who jumped in and couldn't understand why making a
scheduling program should be any harder than typing in a Word document?

Perhaps programming Windows, compared to programming of longer ago, requires a
great deal of expertise, and the only people who could really be there on the
other end to help you... well, they're probably out there somewhere
*programming* instead of being hired for tech support.  I mean, who would do
tech support if they had enough expertise to really get themselves places
using Delphi?

Ach, just my thoughts..

  --=- Ritchie Annand

Other Threads