At 06:54 AM 4/04/2006, you wrote:

>i have an application that uses applyupdate with a TIBOQuery...
>
>i'd set the transaction object asosiated to AutoCommit and
>ReadCommited..but after that i modify the first record i call a
>procedure that makes the IBOquery1.Post; and IBOQuery1.ApplyUpdates;
>
>The first time is all perfect, but in the same session if i try to
>modify the first record again, the ApplyUpdates don't work anymore
>and the IBOQuery1.UpdatesPending; returns False after the
>modification, but the curious thing here is that for any other record
>in the relation works fine, but just with the previously modified not.
>
>I mean the second call to applyupdates for any record is no working.
>.. we test this using IBO 4.2 Ie and 4.6a with the same effect.
>
>What are we doing wrong???

Don't call Post on a cached dataset! That totally defeats the
purpose of caching. Caching is designed to *prevent* Post being
called on any changes in the buffer. When ApplyUpdates is called, it
goes through the buffer and calls Post for each row that has changed
since the last time it was called.

>is this a bug in IBO??? we have found a lot of topics about problems
>with the cachedupdates in IBO but this case is not mentioned in any one

Over the years we have seen quite a few postings about problems with
cached updates, but they usually turn out to be caused by people not
understanding what caching is actually intended to do.

In the BDE model, people often used caching to work around the
inability of the TDataset to retain the data in uncached dataset
after the changes have been posted. IBX and most of the other direct
access components also suffer from this problem.

IBO not only retains the buffers after a commit but it provides a lot
of options to affect what the user sees after a commit or a refresh.

So, those coming to IBO from other component models often believe
that they MUST use caching to keep a constant view of work done. In
IBO, it's not needed. Really, the only time you might want to use
caching with IBO is where you REALLY DO want the ability to separate
the user's work from the "live" database, e.g. for a remote data
module or a web server layer.

So - most of the time - when people think that "caching doesn't work
properly" in IBO, it is because they are trying to use it the way the
IBX and BDE implementations *require* you to use it, just in order to
give the user a consistent view of work done. That is not what
caching was designed for.

You don't need caching in 2-tier IBO applications.

Helen