Una prueba rápida aquí muestra que NULL debería hacer el trabajo. Ejemplo de código que usé para probar (en un formulario simple con un botón y un cuadro de texto):
Private Sub Command1_Click()
Dim dbConn As ADODB.Connection
Dim dbComm As ADODB.Command
Dim dbRS As ADODB.Recordset
Set dbConn = New ADODB.Connection
With dbConn
.ConnectionString = "...REPLACE THIS ACCORDINGLY..."
.ConnectionTimeout = 10
.Open
End With
Set dbComm = New ADODB.Command
With dbComm
.ActiveConnection = dbConn
.CommandType = adCmdStoredProc
.CommandText = "usp_Bob"
.Parameters.Append .CreateParameter("b", adVarChar, adParamInput, 10, Null)
Set dbRS = .Execute
End With
Text1.Text = dbRS.Fields.Item(0).Value
dbRS.Close
dbConn.Close
End Sub
Y llamó a este proceso almacenado:
ALTER PROCEDURE usp_Bob
@b VARCHAR(10)
AS
IF @b IS NULL
SELECT 'NULL' AS '1'
ELSE
IF @b = ''
SELECT 'EMPTY' AS '1'
ELSE
SELECT 'NOT NULL AND NOT EMPTY' AS '1'
usp_Bob devolvió 'NULL' por usar el valor VB Null (según el ejemplo anterior) y 'NOT NULL' para vbNull . Si Null no funciona para ti, ¡entonces no puedo comentar qué podría estar mal...!
Del mismo modo, las cadenas vacías deben pasarse así:una cadena vacía, es decir, str = "" -- lo que hace que usp_Bob devuelva 'VACÍO'. Cualquier otra cosa tiene que devolver 'NO NULO Y NO VACÍO' (como se esperaba).
Si no puede pasar NULL, entonces otra opción es convertir una cadena vacía en NULL en el sproc, es decir,
IF @param = ''
SET @param = NULL
Tenga en cuenta que la longitud por la que pasa no debería importar demasiado. Es un reflejo de la longitud máxima del parámetro tal como se define en SQL Server en lugar de la longitud de los datos que está pasando.
