Helen Borrie wrote:

>
> At 01:48 PM 23-10-02 +0930, you wrote:
> >In the Contact demo, making changes to more than one record and then
> >clicking on the
> >ApplyUpdates button brings up a message 'Transaction has pending changes',
> >even though I
> >had already posted the changes for each record.
> >
> >What is the different between Post and ApplyUpdates?
>
> Post applies the changes to the current row of a live
> dataset; ApplyUpdates applies the changes that have been done to a cached
> dataset since the last time ApplyUpdates was called. Are you using
> CachedUpdates?

In the Contact demo none of the 3 queries have cached updates. Does this mean that the
ApplyUpdates button should have been a commit button instead?

The code in the ApplyUpdatesClick:

dmContact.trContact.ApplyUpdates([dmContact.qrContact]);

This only works when changes to a single record are made.

>
> >Why doesn't ApplyUpdates apply updates to all changes in the table passed
> >as a parameter
> >to the transaction?
>
> Not sure what the question means. A table isn't passed as a parameter to
> the transaction. A transaction gets its parameters when it is started. At

The query (sorry, not table) is passed as a parameter to the transaction component's
ApplyUpdates method; see above.

> that point, it doesn't know about any tables that are going to be in its
> purview. A table identifier will appear in the "FROM" clause of the SQL
> statement that the client passes to the server in the update request, but
> it isn't an attribute of a transaction.
>
> If you have CachedUpdates active, there are two ApplyUpdates calls
> available: one for the dataset, the other for the transaction. If you
> call the transaction's ApplyUpdates method, you can pass a list of cached
> datasets in the call to specify a particular order of processing them. An
> empty set causes the transaction just to iterate through the cached
> datasets in no particular order.
>
> The transaction's ApplyUpdates method also causes a commit. A dataset's
> ApplyUpdates does not.
>

Apparently the commit will only work for a single record's change. Perhaps this is because
CachedUpdates is False. Aha! I just tested this theory and I am right.

Therefore the demo should have had either

(a) Cached updates set on the query;
or
(b) used Commit rather than ApplyUpdates.

Thanks for your help.

--
Raymond Kennington
Programming Solutions
W2W Team B