We're using 6.0.9 and output parms aren't being populated.  I can execute a function mapped from the stored procedure directly from LinqPad (we build a separate EF context project so that we can use our domain models in LinqPad) and the results show up but when executing the function from the IB generated code on the BOS (so it's just executed synchronously), the function executes, hits the db, returns but no values are in the parms. 

 

I've tried having the procedure both return any result sets and not return a result and and it doesn't make any difference.

I've also tried making the output parms nullable but that doesn't help either.

 

I'm not sure the fact that DevForce is making the parms NULLable is really the problem.  I changed the generated designer file to switch the 2 output parms to plain Int32  and Int64 (for my case) non-nullable and they still don't get populated.

 

I've had to switch to returning these as a result set row and just map them to a complex type which works just fine. And even with a result set coming back and me iterating over it, the output parms still aren't set.

:-(

 

This isn't really a bug, we just don't yet support out parameters from stored procedures.   We've got a new release coming next week so won't be getting this working by then, but we can take a look at this for the following release, which would be 6.1.2 in late July.  Can you contact your accout executive about this, so we can determine the priority and timing?

 

One of the main reasons to use an output parm is that EF doesn't send back the Stored Procedure's return code which is a huge failure on their part (at least in my opinion).  Since we've got an existing Windows-based product that has to integrate with the SL/WPF-browser product, we can't change the way those procedures work so either our .net code would have to ignore the SP return code (not really an option for error handling) or we'll write wrapper SPs that we call from the .net side that in turn call the real SP and were planning on stuffing the actual return code from the real stored procedures into the output parm of the wrapper.  If the output parms don't' bubble back up through DevForce, we'd have to create a complex type that encompasses both the return code from the SP and whatever result set it returns and always return a row even if there's a faillure so we can access the return code.  A kludge at best and doesn't really work if the SP maps instead to an entity set.

 

If DevForce supports the output parms, then at least the return code can be handled in a common way regardless of whether the returned set is mapped to an entity or a complex type.

 

So we'll proceed with using output parms and 'assume' you'll have this in sometime this summer.