Szybki test tutaj pokazuje, że NULL powinien załatwić sprawę. Przykładowy kod, którego użyłem do testowania (na prostym formularzu z jednym przyciskiem i jednym polem tekstowym):
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
I nazwał ten przechowywany proces:
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 zwrócił 'NULL' za użycie wartości VB Null
(jak w przykładzie powyżej) i 'NOT NULL' dla vbNull
. Jeśli Null
nie działa dla Ciebie, więc nie mogę komentować, co może być nie tak...!
Podobnie, puste ciągi powinny być przekazywane tak samo - pusty ciąg, tj. str = ""
-- co powoduje, że usp_Bob zwraca 'EMPTY'. Wszystko inne ma to zwracać „NIE NULL I NIE PUSTY” (zgodnie z oczekiwaniami).
Jeśli nie możesz przejść przez NULL, to inną opcją jest rzutowanie pustego łańcucha na NULL w sproc, np.
IF @param = ''
SET @param = NULL
Pamiętaj, że długość, przez którą przechodzisz, nie powinna mieć większego znaczenia. Jest to odzwierciedlenie maksymalnej długości parametru zdefiniowanej w SQL Server, a nie długości danych, przez które przechodzisz.