Hi,

I created this post to continue the problem I post at Memory leak thread. I am not sure should I add mine to the post "Transaction Fail".



Anyway, I have created a simple project which reproduce the error I mentioned if save more than one BO within "same" transaction.



Beside, I also attached screenshot to show the actual error happen before I call Rollback; Also, the screenshot that show "SqlTransaction has completed" error.



As I found that, DataSource.Transactions[0].Connection become null just after the code below when first BO.Save() is called.





Please advice.



Thank you

Hi,

I just come across this forum post, and it mentioned it is SqlTransaction.Connection property goes null randomly is actually ADO.NET bug. It provides workaround as well.



I am not sure if this bug is still exist in ADO.NET as this post is dated year 2007.



http://www.ormapper.net/Forums/Default.aspx?part=74&action=thread&id=2450&key=IaC12zYu0ykFv3qP9v11Tg%3D%3D

Hi,

I do further testing and found that, the transaction.connection goes null just after loReader.Close() is executed. I checked the code and found that SF use do the following in InternalExecuteReader(). Do you think it is the cause?







I attached screenshot to show Watch window shown Transaction.Connection has something, but goes null after Reader.Close().



Hope my information helps and not confuse you.



Thank you

We set the connection object only on certain areas.  This is not one of them.  For example, when you call the FillDataTable method on a BO and pass a DbCommand object, we will set the Connection automatically.  However, this is the only type of scenario that we do this withing the framework.

Where is this code that you are showing screen shots of?

Hi,

It is at SqlDataSourceItem.UpdateRow().

ChanKK,

I believe Trent is asking in which class/method/BO is the transactional code?

Edhy Rijo

Hi,

Sorry, I didn't get you.



I have attached the sample project, this behavour can be "seen" when first BO.Save() is called.

Chan,

I will post on the other thread also, but we found where we had made a change to improve transaction performance.  If you were NOT using SPROCS for your inserts and updates on a transaction, the error you are referring to would occur.  By default we do everything with SPROCS, but the ExecuteReader was being closed.  The build that has just been posted will fix the SqlTransaction issue you have been running into.