I have the following store procedure in the DDT
@pEmployeePK INT,@pServiceCallsScheduleDate DATETIMEASSELECT DISTINCT dbo.ServiceCalls.*FROM dbo.ServiceCallsRIGHT OUTER JOIN dbo.SC_AppliancesON (dbo.ServiceCalls.PK_ServiceCalls = dbo.SC_Appliances.FK_ServiceCalls)WHERE (dbo.ServiceCalls.Status NOT IN (2,3))AND (dbo.SC_Appliances.IncludeInSCRoute = 1)AND (dbo.SC_Appliances.FK_Employees = @pEmployeePK)AND (dbo.SC_Appliances.ServicedDate = @pServiceCallsScheduleDate);SELECT DISTINCT dbo.SC_Appliances.* FROM dbo.SC_AppliancesRIGHT OUTER JOIN dbo.ServiceCallsON (dbo.SC_Appliances.FK_ServiceCalls = dbo.ServiceCalls.PK_ServiceCalls)WHERE (dbo.ServiceCalls.Status NOT IN (2,3))AND (dbo.SC_Appliances.IncludeInSCRoute = 1)AND (dbo.SC_Appliances.FK_Employees = @pEmployeePK)AND (dbo.SC_Appliances.ServicedDate = @pServiceCallsScheduleDate);
@pEmployeePK
@pServiceCallsScheduleDate
AS
SELECT
FROM
WHERE
The parameter @pEmployeePK should be optional, which mean, that I can either pass a value or pass 0, in VB code I would simple do something like this:
If tEmployeePK > 0 Then cmd.Parameters.AddWithValue("@pEmployeePK", tEmployeePK).SqlDbType = SqlDbType.BigIntEnd If
If
cmd.Parameters.AddWithValue(
How would I code the same condition in T-SQL for the store 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.BigIntYou can do something along the lines of the following to account for it in your SQL:@pEmployeePK INT,@pServiceCallsScheduleDate DATETIMEASBEGINSELECT DISTINCT dbo.ServiceCalls.*FROM dbo.ServiceCalls AS SCLEFT JOIN dbo.SC_Appliances AS SCA ON SC.PK_ServiceCalls = SCA.FK_ServiceCallsWHERE 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. Acouple 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.
You can do something along the lines of the following to account for it in your SQL:
@pServiceCallsScheduleDate DATETIME
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.
Thanks a lot, I made the suggested changes and the SP is now working as expected. I am very, very new to SP and now that I have my reports queries working on the VB side, I am moving them to SP to try to speed up the reporting process.