That is exactly what happened to me.  The only way I could get my import routine to work was with the NOLOCK.  I don't know if this is the best way to do it but I couldn't find any other way to get it to work.  If you come up with some thing please let me know,  I will do the same.

Scott

Thanks Scott, this solution worked fine, however I'm concerned if this is a work around or standard practice when implementing transactions.  Based on the information Ben supplied with respect to isolation levels, the ReadUncommitted should have worked...Actually I tried them all and none of them worked for repeated reads.

Right now I have a FillByItemNumber method in my InventoryBO. I use this anytime I want to retrieve an inventory record.  Does this mean I need to create another method FillByItemNumberNoLock and use this anytime I want to update the item muliple time within a transaction? 

I just wanted to make sure.

No, the problem is on my local development machine.

Tim,

Are you running your assembly from a network drive in this scenario?  There could be some additional trust and policy issues.

I ran into a similar situation,  look into using the

WITH (NOLOCK)

clause, that did the trick for me.

Nope, no other suggestions right now... but I'll keep thinking about it.

Changing the Isolation level to ReadUncommitted did not solve the problem.  The program works fine without transactions so I guess I will have to experiment unless you have any other suggestions.

I know for certain that the data access did not change from 1.4 to 1.5, and the transaction processing hasn't changed since 1.3... According to the documentation for ReadCommitted, SQL Server will use locks to prevent reading of uncommitted tables, you should probably use ReadUncommitted in this case.  From the .NET documentation:

	Member name	Description
	Chaos	The pending changes from more highly isolated transactions cannot be overwritten.
	ReadCommitted	Shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in non-repeatable reads or phantom data.
	ReadUncommitted	A dirty read is possible, meaning that no shared locks are issued and no exclusive locks are honored.
	RepeatableRead	Locks are placed on all data that is used in a query, preventing other users from updating the data. Prevents non-repeatable reads but phantom rows are still possible.
	Serializable	A range lock is placed on the DataSet, preventing other users from updating or inserting rows into the dataset until the transaction is complete.
	Snapshot	Reduces blocking by storing a version of data that one application can read while another is modifying the same data. Indicates that from one transaction you cannot see changes made in other transactions, even if you requery.
	Unspecified	A different isolation level than the one specified is being used, but the level cannot be determined.  When using OdbcTransaction, if you do not set IsolationLevel or you set IsolationLevel to Unspecied, the transaction executes according to the default isolation level of the underlying ODBC driver.

I am using IsolationLevel.ReadCommitted.  Did something change in 1.5 because I'm fairly certain my code worked under 1.4?

The issue also comes up when I try updating my inventory file.  If I have two or more of the same item in the same transaction, the first record works fine but subsequent reads fail.

Thanks,
Tim