Stored procedure returns null to VB - sql-server

Question

I have a problem I just can't figure out, my Google-fu has failed me too, so I signed in just to get some expert help.
The problem is complex, with a few red herrings, for what I can figure out, plus as we deal with sensitive information, I can't give the exact code. Please bear with me, I'll try to be as precise and descriptive as I can.
Short version of the problem: I have a stored procedure (on a SQL Server 2008 R2 server) which returns one row when executed directly on the server. When the same stored procedure is executed via VB.net code (Visual Studio 2013 environment), one of the column's value is changed to DBNull.
Long version with code example:
Here is a cleaned up version of the stored procedure
Create PROCEDURE MySP
#inputParms [five of them]
AS
BEGIN
DECLARE #UserCanRun int
DECLARE #ThisApp INT
EXEC #UserCanRun = dbname.dbo.CheckUserCanRun #InputParm1, #ThisApp --security check
IF #UserCanRun = 0 --Means no problem, can continue
BEGIN
DECLARE #ExtraInfo varchar(100)
SELECT #ExtraInfo = typeID + ' - ' + typeName
FROM [three joined tables]
WHERE [conditions using some #InputParm4]
SELECT DISTINCT
col1, ..., [colN-1], #ExtraInfo as colN, [colN+1], ..., colM
FROM
[8 joined tables and subqueries]
WHERE
[more conditions with #InputParms2 to 5]
END
END
GO
This stored procedure runs just fine when executed directly on the database; it returns one row, with all the (available) info having their value set correctly. (You'll notice colN; it's the one giving me trouble; co-workers assure me the fact it is using value from a variable shouldn't be a problem.)
Now, when I call it from VB.net code:
dim rTable As DataTable
dim myCmd = New SqlCommand(SPName, myConnectionString)
dim parameter As SQLParameter
dim rValue As Integer = 0
[set SQL parameters]
If not myCmd is Nothing Then
If myCmd.Connection.State = connectionstate.Closed Then
[bit of security check code]
command.Connection.Open()
End If
Dim myAdapter As New SqlDataAdapter
myAdapter.SelectCommand = myCmd
myAdapter.Fill(rTable) 'problem!
ReturnValue = CInt(myCmd.Parameters(RETURN_VALUE_FIELD).Value)
End If
[more code]
If I do a quick watch on the rTable after the myAdapter.Fill command has executed, the value rTable.Rows(0).Item([M]) returns DBNull, while it was not DBNull when fetched directly in the SP, using exactly the same parameters.
I don't have a data set for that table; you can see it uses a generic DataTable (the code is adapted from an application specific object to simplify all stored procedure calls, so I can't create a dataset and use it at this level either). So I don't think.
I have checked for the validity of the value; I have even checked the Unicode value of each character of the #ExtraInfo value to make sure there was not some control character that would have been put in accidentally. It matched the value shown, so no bad character messing up the value.
This is used in a few places in the code, but seems to fail for one specific set of data on our production environment; I haven't been able to reproduce the problem on our development environment. So I can't just go in and play with it.
Would anyone know what else could cause a column's value to go from a non-null, non-empty varchar to DBNull by going through SqlDataAdapter.Fill()? I can't step into that call, so I am blind.
(Also worth of note, maybe: I have been using VB.net for only about two years, debugging existing systems, so I may be missing something obvious; although my more experienced colleagues don't understand it either.)
Edited to add the final word on the problem: I never found the solution, except good old Murphy's Law. After letting this aside for a while, I asked a co-worker to take a look. As I was showing him, the problem didn't occur. Another test later confirmed it was behaving normally. I can't promise anyone Murphy's law is a sure solution, but I can only suggest there was some transient error that disappeared on its own. If it happens to you, good luck, and please let us know if you find a solution, or even a way to diagnose it. Thank you!

Answer 1

Your stored procedure needs SET NOCOUNT ON at the beginning