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