Using this technique, I’m pooling a large collection of records to be passed as XML to a SQL Server (2008R2) proc from a .NET 4.0 app. The proc prepares the XML and joins against it using OPENXML (or at least will when I get it working).
When the code executes, .NET appears to correctly build the parameter and add it to the SQL command, but when it calls SQL Server, the SQL Profiler shows the parameter as null.
exec jcsdmp_UpdateMultiDocumentSendStatus @pUpdateStatusesXML=NULL
The calling code:
SqlParameter[] UpdateParams = new SqlParameter[1];
UpdateParams[0] = new SqlParameter("@pUpdateStatusesXML", SqlDbType.NText, sb.ToString().Length, sb.ToString());
SqlAccess.ExecuteNonQuery("docmgmt", "jcsdmp_UpdateMultiDocumentSendStatus", CommandType.StoredProcedure, UpdateParams);
And yes, I’ve been looking into the custom SqlAccess class (which largely checks parameters, opens connections, etc.–no real magic), but so far it looks like .NET thinks it’s sending the parameter…
Is there a size limit I might be missing or something along those lines?
For the
SqlParameterconstructor overload you’re using, the fourth parameter is not the value but the source column.Have you tried using the constructor overload that accepts the value, and it will infer the type and size?
You can explicitly set the SqlDbType after this if you need to (it may infer NVarChar):