Subject Re: Re: [IBO] ClientDataset.ApplyUpdates doesn't save BLOB field to FB

this is not a problem of IBO, but a TClientDataSet issue. Go to Borlands

Quality Central and look for issue #2026 (if i remember correctly).

TClientDatasets dont read blobs in the delta and thus, if your blob is
not changed - and the provider tries to write the oldvalue, than this
oldvalue is emty - and the data gets erased in the database.

There is a 'hack' to overcome this by telling the TClientDataSet to
always read blobs.

Regards, Matthias

Helen Borrie <helebor@...> schrieb am 30.08.2004, 03:51:16:
> 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.
> >(
> > "field1" INTEGER NOT NULL,
> > "field2" VARCHAR(10),
> > 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
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more !
> Yahoo! Groups Links
> To visit your group on the web, go to:
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to: