Home Page for the TeradataForum

Archives of the TeradataForum

Message Posted: Fri, 08 Mar 2002 @ 10:36:16 GMT

  <Prev Next>   <<First <Prev Next> Last>>  

Subj:   Re: Teradata locking mechanism vs. Oracle
From:   David Wellman


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)

  <Prev Next>   <<First <Prev Next> Last>>  
  Top Home Privacy Feedback  
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 15 Jun 2023