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??? doesn't clientdataset.applyupdates(n) start a
transaction and commit it or rollbak it itself???

don´t you have any examples ABOUT datasnap with IBO??

THANKS

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 08:03 AM 28/12/2006, you wrote:
> >Yes, my ResolveToDataset property is set to true.
> >
> >About AfterApplyUpdates event, I didn't know that I 've to commit
the
> >transaction.
>
> Everything in Firebird/InterBase is isolated
> inside a transaction. A transaction ends by
> being committed or rolled back. Until the
> transaction in which an operation occurs is
> committed, the effects remain isolated from all other transactions.
>
> >Is it because the ResolveToDataset property???
>
> A ClientDataset object doesn't have to have a
> database set as its provider. It can be a text
> file, e.g. a .csv file. The ResolveToDataset
> property tells the CDS that there is a database
> engine beneath the provider, that is providing
> the set according to its own rules. You
> therefore set ResolveToDataset to true and use
> the provider's events to pass instructions back to the dataset.
>
> >Anyway I did it but doesn´t work.
> >I realised that it didn´t pass through the "if TransactionIsActive
> >then"
> >condition so I remarked it. But it didn´t work neither
>
> I noticed in your first posting that you were
> using your previous experience with Paradox as a
> guideline for what you should do with
> Fb/IB. Paradox and Fb/IB are two completely
> different animals. So - please don't take
> offence if you get some advice here that you
> think is insulting. We have no way to tell
> whether you understand the basics of working with
> a transactional database engine.
>
> Therefore, my prime advice is that, if you
> haven't used a transactional database engine
> before, then don't begin your experience with
> TClientDataset. Play with the 2-tier model to
> begin with, so that you get comfortable with
> transaction isolation. Then, when you come
> around to implementing your n-tier application
> model, you are almost certainly going to want
> something more capable than TClientDataset, such as RemObjects, etc.
>
> In the process, you need to understand that the
> results of one transaction won't be seen by
> another transaction until after *both*
> transactions have finished. Even if one
> transaction is "just looking", it is still an
> isolated translation that can see only the
> changes it has made itself. This applies not
> just to your client programs but also to any data
> viewing tool you might be using: isql, IB_SQL,
> Database Workbench, IBExpert, etc.
>
> There is one transaction isolation - Read
> Committed, surfaced in IBO as tiReadCommitted -
> that allows the transaction to see the committed
> work of others *before* it is itself
> committed. However, the user interface won't see
> the effects of those other changes unless it
> refreshes the datasets it is viewing.
>
> -- You should find a Refresh button or menu
> option on any GUI tools you might be using. In
> IB_SQL, its glyph is a curved black arrow
> superimposed on a yellow one. IB_SQL uses Read Committed isolation
by default.
>
> -- If you are using isql, which runs in
> Concurrency isolation, you would always need to
> call commit and then repeat your SELECT query to
> see the results of your application's work.
>
> As a reality check, test whether the reason you
> can't see the results of your application tests
> is due to transaction isolation.
>
> Helen
>