They may need to use IBO 4.7 Beta12.
They can test with the eval version.

I have some fixes to the provider stuff in it.

Jason

> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]On
> Behalf Of Helen Borrie
> Sent: Thursday, December 28, 2006 3:54 PM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] Applyupdates doesn't work
> (TDataSetProvider+TClienteDataSet+TIBOQuery)
>
>
> At 05:58 AM 29/12/2006, you wrote:
> >Helen, as i told you in the first posting, i´ve already
> worked with 2-
> >tier aplications so I 've read a lot about transactions and i know
> >about what your are writing about. So i am sure it is not a
> >transaction problem.
> >
> >On the other hand. Why should i commit a transaction when working
> >with tclientdataset???
>
> All operations - including the SELECT that
> delivers data to the CDS - happen (and can only
> happen) within transactions. So updates, deletes
> and inserts that you perform within the
> transaction that is feeding the CDS have to be
> *committed* to become permanent in the database (or rolled
> back to be undone).
>
> >doesn't clientdataset.applyupdates(n) start a
> >transaction and commit it or rollbak it itself???
>
> No. A CDS is not itself a provider, it is just a
> container for data that you want to show the
> user. ApplyUpdates (a) won't work if the CDS is
> looking at data that was selected during a
> transaction that the provider's dataset has
> completed or rolled back; and (b) merely asks
> the provider to tell the dataset to *post* the
> changes. "Post" is a Delphi concept that equates
> to a Fb/IB DML request: if it succeeds, a new
> record version is created on the server that is
> not accessible by any other transaction. The
> "posted" work remains uncommitted until it is committed.
>
> Unless the dataset is in an Autocommit
> transaction (not recommended!) the posted work
> must be committed in order to become permanent.
> That's why your provider needs to follow up its
> ApplyUpdates call with a heads-up to the dataset
> to commit its transaction (if that is what you want, of course).
>
> >don´t you have any examples ABOUT datasnap with IBO??
>
> No. It could be an interesting thing (albeit
> rather futile in practical terms) to do as an
> academic exercise, but it's not really a
> technology that commends itself to Fb/IB
> work. It's designed to extend the range of
> ISAM-style databases (Paradox, MySQL, Access,
> etc.) It's totally not needed for 2-tier and it
> has too many shortcomings to be useful for n-tier
> work with a transactional, MGA database
> architecture. There's a rich field of
> third-party components out there that do n-tier
> beautifully and properly for Fb/IB backends,
> including Asta and RemObjects that support IBO data access.
>
> That said, there's no reason I know of why it
> shouldn't work. If it doesn't seem to be working
> for you, we need to find out why. I'll try to
> make a small sample app over the weekend, using
> the employee database, and post it into the Files
> area of the list if it works. It would be useful
> at least from the POV of identifying some
> possible bug that's lurking in this infrequently-visited area. :-)
>
> Helen
>
>