LLBLGen Pro v3.0 Final (July 12, 2010) C# 4.0 Adapter Template

I have a sproc in my database that returns both result sets and output parameters.

In version 2.6, the ...AsQuery method of calling the sproc did not accept arguments for the output parameters, for reasons that I understand, and are documented in this thread: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7153

Now, when upgrading to 3.0, I see that these output parameters are now included in the ...AsQuery method's parameters, and even as "ref" parameters, but I've found that the "ref" is misleading, because the generated code will never set the value.

It seems to me that if the parameter is an output parameter, then it makes sense to include it in the ...AsQuery method, but not as a "ref" parameter". This will mislead people into thinking that the method will set the value, which it will not.

Thanks,

Wesley

Hmm - I'd have expected the value to be set for the Output parameter, there's not a lot of point it being there otherwise.

Can you post the code you are using, so we can see if there is any reason why you're not getting a value in these parameters.

Cheers

Matt

The reason this is, is because the same code is used to produce the call object as in the normal method. I.o.w.: a member has to be passed otherwise we'd have to create the same method twice as we did in v2

You ran into the situation where this broke your code?

No, it did not really break my code. In 2.6, I had code like this:

query = RetrievalProcedures.XXXCallAsQuery(arg1, arg2, arg3)

Now, I've changed it to add the additional argument:

int ignore = 0;
query = RetrievalProcedures.XXXCallAsQuery(arg1, arg2, arg3, ref ignore)

In both cases, I manually pull the output parameter's value out after I've read all of the result sets:

SqlParameter newTimestampParameter = query.Parameters[3] as SqlParameter;
timestamp = (long)newTimestampParameter.Value;

So, that's an easy fix for me to make - I just wasn't sure that you intended for that to be how it would work, and I think that the "ref" parameter might mislead users of the API to think that that value will be set (and thus create more help requests when it doesn't)

Thanks,

Wesley

yes, that's a good point.

Changing it again will cause code breakage, unfortunately, so we can't correct it. But we should have payed more attention when creating the methods. I'll make a note that we correct this in the next v3.x version.

You mentioned correcting in v3.x? Has this been fixed? We are on 3.5 and just run across this issue with the *AsQuery version of the method.

Also on a side note: // [C#] int outputValue; DataTable resultSet = RetrievalProcedures.MyStoredProcedure(1, 2, 3, 4, ref outputValue);

in http://www.llblgen.com/documentation/3.5/LLBLGen%20Pro%20RTF/hh_start.htm (not sure how to link to the specific article, and google only finds the 2.6 version of the article)

will not compile due to "Use of unassigned local variable". This took me down a bit of a tangent thinking I was doing something wrong. If I did assign it a value, it would keep that value and ignore whatever the SP's out param was set to.

Thanks.

And thanks to wesleysmith for the workaround.

You still have to use a workaround, as it's not possible to update the value of your var the a ...AsQuery call, because the reason explained by Frans.

You mentioned correcting in v3.x? Has this been fixed?

Not fixed, it breaks too much code, so we won't change it.

Otis wrote:

You mentioned correcting in v3.x? Has this been fixed?

Not fixed, it breaks too much code, so we won't change it.

Frans, with v4 on the horizon, can this be considered as a "breaking change"? I'd love to see this corrected, but I understand you don't want to break things for existing users. Version 4 could be the opportunity to correct this bug.

aspicer wrote:

Otis wrote:

You mentioned correcting in v3.x? Has this been fixed?

Not fixed, it breaks too much code, so we won't change it.

Frans, with v4 on the horizon, can this be considered as a "breaking change"? I'd love to see this corrected, but I understand you don't want to break things for existing users. Version 4 could be the opportunity to correct this bug.

Changing it would mean that anyone who has output parameters will have to correct all calls to the methods. All of them. I don't mind breaking a method signature which is meant to be overriden, that's a change which the user will not be wasting a lot of time on. However this could lead to many calls which have to be altered, which is something we won't force upon users. It sucks, but it's one of those things which are unfortunately there and will stay there, as removing them / changing them will cause a big burden for people upgrading.