How to handle transaction in BASIC ROUTINE

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
Rubu
Premium Member
Premium Member
Posts: 82
Joined: Sun Feb 27, 2005 9:09 pm
Location: Bangalore

How to handle transaction in BASIC ROUTINE

Post by Rubu »

Hi All

My requirement is to read a row from a table. Then I want to update it with a new value. But untill I update the row, it should not be updated by any other application....... I think if I can lock the row after reading , untill we update it ..this purpose is served....

OR I can do both the operations inside a transaction block as follows...

BEGING TRANSACTION
select * from table
then store the value in some file,
update the row
END TRANSACTION

Please suggest me how to achieve it in datastage. Can I write a Basic routine for that... Any sample routine available??

Regards
rubu
davidnemirovsky
Participant
Posts: 85
Joined: Fri Jun 04, 2004 2:30 am
Location: Melbourne, Australia
Contact:

Post by davidnemirovsky »

You can obviously do this a few ways. I would personally use Semaphores for locking and unlocking processes you need shared.

This post will help you get started: <a href="viewtopic.php?t=84481&highlight=semaphores">Click here.</a>
Cheers,
Dave Nemirovsky
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

If the routine is connecting to DataStage database (hashed files, UV tables) then you can use BEGIN TRANSACTION, COMMIT, ROLLBACK and END TRANSACTION as you seek to do.

If you are accessing other databases via the BASIC SQL Client Interface (BCI), then you use SQLSetConnectOptions() to specify manual control of transactions, then SQLTransaction() actually to control the transaction.

Otherwise, it can't be done from BASIC as true transactions in the target database, which is why people like David resort to other techniques. However, these provide no protection against other processes interacting with your target database.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply