|
Question : Begin/Commit Nested Transactions in VFP/Sql Server environment
|
|
Hi Folks,
In my VFP 8.0 app, when a user clicks on the MODIFY button, I want to lock the row right away (Pessimistic). I do not use a VFP transaction, but rather a sql server transaction as follows:
*-- set sql server timeout to 5 seconds, begin the transaction, then select with two lock hints. lcSqlExec = "SET LOCK_TIMEOUT 5000 " + ; " BEGIN TRANSACTION " + ; " Select * From " + tabl_lock + " WITH (UPDLOCK,ROWLOCK) " + " Where Pkey = " + lcPkey lnResult = SQLExec(gnConnection, lcSqlExec, 'c_TableLocked')
So far, this works fine. In other words, if I go to a QA Sql session (or another VFP session) and issue the same exact Select as above (same tabl_lock and lcPkey), it WILL time out.
Now...when the user finishes his modification he simply cliks the OK button. Behind the scenes I exec an Update stored procedure. Within that proc, I begin/commit a nested transaction as follows: ... SET @SqlStr = @SqlStr + ' WHERE ' + @pSqlWhere BEGIN TRANSACTION EXEC sp_executeSql @SqlStr -- this runs the dynamic Update command COMMIT TRANSACTION .....
Now the confusing part is that after I exec this procedure, it appears that my first transaction has auto-commited. My first tran should still be open, no ?
I know this because I check the value of the sql server system var @@trancount before AND after I exec the Update stored proc :
=SQLExec(gnConnection, "select @@trancount as transaction_count", 'c_TranCount')
Before I exec my stored proc, @@trancount shows 1 transaction. As soon as I exec the stored proc, @@trancount returns a zero. WHY ??? I should still be running within my original transaction that I started up above (when locking the row).
This doesn't allow me to cleanly COMMIT my first transaction via SqlExec() ....I don't understand why this happens...
thank you, John
|
|
Answer : Begin/Commit Nested Transactions in VFP/Sql Server environment
|
|
Closed, no 125 points refunded.
modulo Community Support Moderator Experts Exchange
|
|
|
|