You always have to supply it, but you can account for it as you have already mentioned by passing over a 0 and handling the 0 within the logic of your stored procedure. So you're VB code would look like this (take out the IF test and pass it even if the value is 0):
cmd.Parameters.AddWithValue("@pEmployeePK", tEmployeePK).SqlDbType = SqlDbType.BigInt
You can do something along the lines of the following to account for it in your SQL:
@pEmployeePK INT,
@pServiceCallsScheduleDate DATETIME
AS
BEGIN
SELECT DISTINCT
dbo.ServiceCalls.*
FROM dbo.ServiceCalls AS SC
LEFT JOIN dbo.SC_Appliances AS SCA ON SC.PK_ServiceCalls = SCA.FK_ServiceCalls
WHERE dbo.ServiceCalls.Status NOT IN (2,3) AND
dbo.SC_Appliances.IncludeInSCRoute = 1 AND
(@pEmployeePK = 0 OR dbo.SC_Appliances.FK_Employees = @pEmployeePK) AND
dbo.SC_Appliances.ServicedDate = @pServiceCallsScheduleDate;
...
END
I accounted for the possibility of hte employeePK being 0 through the italicized where condition with the OR in it. A
couple of things to keep in mind:
1) I used an OR above for clarities sake. ORs tend to slow things down in SQL, though, so if this is a query that
is used a lot or that needs high performance, I would look at a different solution to handle this problem, even down to
having two seperate SQL queries on either side of an IF test.
2) I also have italicized your join and changed it to a LEFT JOIN, though that may not be what you need here. I'm not sure what exactly
your desired results are, but another thing to keep in mind is that OUTER JOINS are slow as all get out in SQL, and RIGHT JOINS aren't
typically used very much either (they are somewhat slow as well, though there are rare circumstances where they are neaded.) Depending
on what you are going for here, you can almost always get the records you need with a LEFT or an INNER join.