SQL Server 2005

LANSA Technical

previous page next page

SQL Server 2005

ODBI=2 (READ_COMMITTED)LockTimeout=2 (X_DBMENV.DAT)

WITH_KEY IO access

Step	Action (User)	IO$STS	Message
1	Insert (1)	OK	IO Operation Succeeded
2	Insert (2)	ER	Record Locked
3	Delete (2)	ER	Record Locked
4	Commit (1)
5	Update (1)	OK	IO Operation Succeeded
6	Update (2)	ER	Record Locked
7	Fetch (1)	OK	IO Operation Succeeded
8	Fetch (2)	ER	Record Locked
9	Commit (1)
10	Delete (1)	OK	IO Operation Succeeded
11	Insert (2)	ER	Record Locked
12	Update (2), Delete (2)	ER	Record Locked
13	Commit (1)

Note the differences between ASA and SQL Server at steps 2, 7 and 12. There may be many ramifications of these differences in attempting to have an application perform the same way on both databases. For example, Step 7 implies that if your application updates a record and doesn't commit it, then re-reads the record, on SQL Server it will work. When you then execute it on ASA, it will timeout if a LockTimeout is set, otherwise it will block.

Last Record Read IO access

This is a different set of steps as there must be a record to read before the last record read can be updated or deleted! Hence when an error occurs, the record must be fetched again like in Step 13.

Step	Action (User)	IO$STS	Message
1	Insert (1)	OK	IO Operation Succeeded
2	Insert (2)	ER	Record Locked
3	Commit (1)
4	Fetch (1), Fetch (2)	OK	IO Operation Succeeded
5	Update (1)	OK	IO Operation Succeeded
6	Update (2)	ER	Record Locked
7	Fetch (1)	OK	IO Operation Succeeded
8	Fetch (2)	ER	Record Locked
9	Commit (1)
10	Fetch (1), Fetch (2)	OK	IO Operation Succeeded
11	Delete (1)	OK	IO Operation Succeeded
12	Insert (2)	ER	Record Locked
13	Fetch (2) Update (2), Fetch (2) Delete (2)	ER	Record Locked
14	Commit (1)

Note that step 13 gets the lock timeout on the Fetch not the Update. Compare this with ASA which reports the row does not exist on the Fetch and Oracle which succeeds on the Fetch but gets the lock timeout on the Update.

previous page start next page