Yes, it throws an exception if an error occurs, so you can use a basic try/catch within your code to handle the error.  The error will come back as a SqlException which has all sorts of properties like the ErrorCode and the Errors collection that will give you extended information on the error.

This post has helped me a ton.  Quick question, is it important to make sure that each transaction has a different name? Ir is it ok to have all Transactions named "MyTrans" or some such.

Thanks,

Robin Giltner

It's perfectly fine for all transactions to have the same name.  But, you can only have one transaction with a specific name at a time.  A transaction's life begins when you call TransactionBegin() and ends when you call TransactionCommit() or TransactionRollback().  So, if you need to have more than one transaction open at a time, you'll have to use a unique name for each one (which will almost always happen in a web environment).

What about with multiple users using the same application on the same database?  And what about the Middle Tier when it comes out?

Thanks,

Robin Giltner

You can still use the same key with multiple users talking to the same database, because the key is only used on the client side.  However, when you add the ES to the mix, the key is used as an identifier by the ES as well, so it would probably be best for you to use a unique key since you're planning on using the ES.

Awesome, thanks Ben.  That should save some heartache at a later date.

Thanks.

Robin Giltner

No problem

I was just wondering  if

DataBasics.DataSources("").ExecuteStoredProcedure("proc Here") 

can be part of a transaction along the lines of

Try

BusinessLayer.TransactionBegin("", Data.IsolationLevel.ReadCommitted)

Me.Customers.Save(True)
Me.Orders.Save(True)

DataBasics.DataSources("").ExecuteStoredProcedure(Do some processing here)  BusinessLayer.TransactionEnd()

 BusinessLayer.TransactionEnd()

Catch

 BusinessLayer.TransactionRollback()

End Try

 

please disreguard above

thanks

Hehe, will do.