Paul,

It is still returning 0 as my ID, it coudl be how I am assigning the returned value though. In my ASP page I have the following:

hidPreClaimID.Value = cntrlr.AddMedicalManagement(addPreClaim)

Does this work?

Chris

Chris,

Yes this should work.   To test - return a static value.  For example,  use "Return 1234"  in the stored procedure.  If you get a value of 1234 returned from the procedure then the issue is in the Stored Procedure, If you get 0, then you  know something is off with the code. 

I have used this method to return values all the time ... no issues.  

Another alternative, is to return the record just added.  Use the value to select the single record added.  Select ... where PreClaimID = @PreClaimID.  Then you can go back to using the ExecuteReader method like all the calls that returns data.

Paul.

Chris,  the second alternative I suggesting was not use any return value or variable at all.  Just have the stored procedure return the record just added.  This new record will contain the identity value as part of the fields returned.   Consider it  the same as combining the add and read functionality in one. 

So the end result is a simple ExecuteReader to read all the fields into the class, just like the read (or list) procedures.

As for the correction to the SQLHelper, I doubt that will happend as the SQLHelper function is defined in a dll supplied by Microsoft. 

To be honest, and just my opinion, with the move to SQL2005, the need for a provider model has been lost. I could see a complete rewrite using something like entity framework.  This would still allow people to use a different Database if required.  DNN 6?