Archives of the TeradataForum

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

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

Hi,

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.

Cheers,

Dave

Ward Analytics Ltd: Information in motion (www.ward-analytics.com)

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