Archives of the TeradataForum
Message Posted: Fri, 08 Mar 2002 @ 10:36:16 GMT
Teradata locking is different and I don't think that you can achieve exactly what you've described.
In the Teradata environment, as soon as Application A issues an Update/Insert/Delete request the appropriate rows in the table WILL be changed.
Whether Application B can see those changes or not depends on the LOCKING statement that Application B uses, however App B will NEVER see the old rows (and to be honest I've never used a DBMS that would allow this -- although Oracle may be different in this respect).
In the Teradata environment, if App B still wants to process the table whilst App A is making changes it can preface an sql Select request "LOCKING TABLE x FOR ACCESS..." which gives a 'dirty read' capability.
That's probably as close as you'll get to what you want using native Teradata capabilities. To achieve what you've described below, you'd have to have App A store the changes in a separate table and then when it comes to the point of doing a 'commit' those changes would need to be applied to the real table.
Hope that explains the situation.
Ward Analytics Ltd: Information in motion (www.ward-analytics.com)
|Copyright 2016 - All Rights Reserved|
|Last Modified: 28 Jun 2020|