At 09:48 AM 30/08/2004 +0900, you wrote:

>Hi
>
>I'm having problems with TIBOQuery - TDataSetProvider - TClientDataSet.
>(Firebird1.5 + IBOv4.2Id + D6)
>
>Thera is a table someting like this.
>CREATE TABLE "TBL_TEST"
>(
> "field1" INTEGER NOT NULL,
> "field2" VARCHAR(10),
> "field3" BLOB SUB_TYPE TEXT SEGMENT SIZE 80,
> PRIMARY KEY ("field1")
>);
>
>TClientDataSet
>
>I Edit field1 or field2 and perform ClientDataSet.ApplyUpdates.
>Then field3(BLOB field) data is lost. Not saved to the FB.
>But when the BLOB field also is edited or only BLOB field is edited, BLOB
>date is not lost.

ApplyUpdates causes the provider's datasource to post changes to the
database but nothing will be committed until Commit is called.

>I made same test with IBX, and it was OK.

Sorry I can't offer a solution to the problem, only some comments about
some essential differences between IBX and IBO.

It's always hard to answer these TClientDataset questions, especially for
people who have gotten into the habit of using IBX. Often, it seems they
are trying to do things in two-tier client/server that don't fit with IBO's
client/server model. More often than not, the question goes into limbo
because an IBO developer doesn't have much (or any!) experience with
IBX. Conceptually, they are very different.

IBX uses an entirely different model for operating a bi-directional
dataset. In IBO you don't need the TClientDataset layer at all, unless
your application is multi-tier. In short, from what I can tell, IBX's
query component seems to implement by default some kind of Autocommit to
the datasource when ApplyUpdates is called, to emulate the original
scrolling behaviour of the TQuery.

IBO does not require the TClientDataset layer for two-tier applications.
TIBOQuery behaves like TQuery, with some additional behaviour inherited
from TIB_BDataset. It does this without resorting to TClientDataset to
achieve an updatable scrolling dataset.

Where blobs are concerned, an "update" never updates a blob: the old blob
is completely replaced by a new one, with a new BLOB_ID. The new BLOB_ID
is available to the application once ApplyUpdates is called (and Post
occurs); but there is no blob in the database until the work is committed.

IBO's two-tier implementation takes care of old and new blob data. I
suspect that posting from a TClientDataset causes the TIBOQuery buffers to
"lose" the connection between the old blob_id and its data node once the
Post is called. In TQuery you could influence this behaviour by setting
the UpdateMode property to upWhereChanged. However, in looking for a
similar workaround for TIBOQuery, it appears that TIBOQuery hides this
property...

I hope someone else can be of more help.

Helen