I have an entry screen that slow down during saving after we put in the transact.Anyway to speed it up? how to efficiently use the transact?

Using Transaction Control adds on more work so it will save more slowly. Last time we checked control on and control off they didn't seem to be working. Have you confirmed that they function correctly?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I did not really check if it works or not because once i put it in it slows down my saving a lot.So if it slows down it should be working right? Let me test it out first.

Also see if the first save is slower because it could have to set up specific transaction files the first time it is used.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

U were right.Not all the control on and off works.So after a long night, i finally got it working.The only file that does not work was the bounded one, all my other files work correctly.Did u face this same problem? If so, here's how i solve it:

I think it is the way oi save the screen data to the record of the bounded file.I think it uses writev instead of a write.The writev somehow is not compatible with the control on or the transact command.It only works with a write.So i just write a blank record to the bounded file with the current key.After that oi takes care of the rest.If revelation staff is monitoring, please confirm this.If possible please fix it.This looks like a bug to me since i am using your control/transact command and your default write for a bounded screen.

So, comming back to the speed.Yes i did notice it was slower on the first time.In fact it gave me a message saying that it cannot find the files in the transact directory.So, after attaching the required files from the transact directory, it was faster but still noticable to a trained eye.Any further steps to take to speed it up?

So, if i were to deploy, i have to deploy the transact directory as well?

Does multiuser compicate more on this issue?

Do any of u guys uses it at all?

You would have to deploy the transact volume. Multiuser use should not make too much of a difference. The speed difference is essentially because the transactions to support the rollback are being made bythe workstation itself - not by the server as would be the case in a client/server environment.

We don't know anybody who is using it BUT we have heard reports that people were very happy with it. We tend to feel that commit and rollback has a lot more applicability in an environment that only permits optmistic locking and non multivalues. A single row written with associated multivalues requires one pessimistic lock and cannot logically fail. The same transaction made in a purely relational system would require multiple table updates thus introducing the possibility of lock failure.

That having been said, a modification to the Universal Driver to support serialised transactions would be a welcome addition :).

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I would agree with Sprezz contention that Transaction tracking is not all that relevent when saving one row. However, we have many instances where we are doing "Batch" posting where each Batch Row actually updates multiple tables. This is the perfect opportunity to use Transaction Tracking.

Are you saying that the Universal Driver is going to have this feature?

Thanks,

John Bouley

I think the inference was that the Universal Drive may have the potential to be extended to offer this feature & this would be a fantastic plus for transaction processing. Like LH3 on steroids.

Richard Bright

BrightIdeas New Zealand

View this thread on the Works forum...