Yes, sorry. SPs on the brain. I have been trying to go from 25 to 85 mph in a week and I guess it showed there.

>Pardon me if I misunderstood (I was up late last night working, and up again early this AM), but you mean from a Stored Procedure, right?
>
>>FWIW I have read that using RETURN to return anything other than a code indicating success or failure is from the dark ages and should be avoided. It sounds like you're on the right track -- OUTPUT parameters are a better way to return data.
>>
>>>Hi everybody,
>>>
>>>I'm wondering if I'm on the right track and how should I modify my code.
>>>
>>>In the project I'm working with right now as a sample I see this code
>>>

>>>/// <summary>
>>>        /// Insert new order
>>>        ///     returns the newly added key.
>>>        /// </summary>
>>>        /// <param name="dr">data row</param>
>>>        /// <returns>primary key of new record</returns>
>>>        public int InsertNewOrder(OrderDataSet.OrdersRow dr)
>>>        {
>>>            OrdersTableAdapter ta = new OrdersTableAdapter();
>>>            
>>>            return (int)ta.InsertOrderRecord(dr.OrderPk, dr.OrderDate);
>>>        }
>>>

>>>
>>>In my case the Orders table has PK as GUID (I want to allow simple merge), ID as Integer Identity and an OrderDate.
>>>My method in TA is
>>>SET @NewOrder = NewID();INSERT INTO [Orders] ([OrderPk], [OrderDate]) VALUES (@NewOrder, GetDate()); SET @NewOrderID = Scope_Identity() and both parameters are set to be Output parameters.
>>>
>>>So, the question is - how should I pass and how can I get them back in the BL?
>>>
>>>Thanks a lot in advance.
>>>
>>>BTW, should I call in each method ta.Dispose() to clean up right away or should I switch to using here ?