Subject | more about transaction/cached updates |
---|---|
Author | Gediminas |
Post date | 2006-03-26T18:13:49Z |
I'm using this a year old post as a base (truly useful post to save
in inbox :))
if TIB_Query (cached updates on) with a SSP is opened (results shown
in IB_Grid) for a long time, isn't that hurting performance? as I
know, transactions should be as short as possible.
Then after a long inactivity, deletion SP is called - so transaction
must be active all the time? maybe that's ok if it doesn't advances
(edit/insert/refresh/delete)?
Queries close and unprepare should be executed under transaction or
transaction may end before this?
As I understand, cached updates work only with the queries
At 03:16 2005-03-21, you wrote:
--= The Truth Is Out There =--
in inbox :))
if TIB_Query (cached updates on) with a SSP is opened (results shown
in IB_Grid) for a long time, isn't that hurting performance? as I
know, transactions should be as short as possible.
Then after a long inactivity, deletion SP is called - so transaction
must be active all the time? maybe that's ok if it doesn't advances
(edit/insert/refresh/delete)?
Queries close and unprepare should be executed under transaction or
transaction may end before this?
As I understand, cached updates work only with the queries
At 03:16 2005-03-21, you wrote:
>Your problem here is that your code separates the cache from theGediminas
>transaction in which the task occurs. The sequence has to be
>
> Transaction.StartTransaction
> Query.Open (or Refresh)
> ...
> Query.Insert
> (insert rows into the cache)
> ... (mess around inside the cache if desired)
> Query.ApplyUpdates (posts all new rows)
> ...
> Transaction.Commit
> Query.CommitUpdates
>
>Caching simply alters the normal course of events for updating datasets,
>which is as follows:
>
> Transaction.StartTransaction
> Query.Open (or Refresh)
> ...
> Query.Insert
> (insert one row, no more messing around)
>
> Query.Post (posts the current row)
> ...
> Transaction.Commit
--= The Truth Is Out There =--