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