SQL Query data based on a variable

Try this:

...WHERE (@LocationId = 1 AND 1=1)
   OR (@LocationId <> 1 AND LocationId = @LocationId)

This seems devilishly simple, perhaps I am not understanding your question. If you want to query by a variable value, then just use the variable value:

DECLARE @LocationId INT = 1

SELECT * 
FROM @temp
WHERE (@LocationId = 1 AND 1=1)
OR (@LocationId <> 1 AND LocationId = @LocationId)

A couple of other ideas. Since using a constant of 1 is not exactly intuitive or self-documenting, you could default that to NULL. And then say:

WHERE LocationID = COALESCE(@LocationID, LocationID);

If LocationID column is nullable, then instead you could use some token value that is at least slightly more self-documenting than 1, like -1 (since I don't think anyone looking at the code will immediately know that there isn't really a valid row where LocationID = 1):

WHERE LocationID = COALESCE(NULLIF(@LocationID, -1), LocationID);

This is susceptible to parameter sniffing, so you might want to add OPTION (RECOMPILE) if you find you are often switching between "all rows" and "very specific rows." You can also use dynamic SQL to optionally build the WHERE clause, assuming your real scenario uses a real table:

DECLARE @sql nvarchar(max) = N'SELECT ... FROM dbo.RealTable'
IF @LocationID <> 1 -- or IS NOT NULL or <> -1 or what have you
BEGIN
  SET @sql += N' WHERE LocationID = @LocationID';
END
EXEC sys.sp_executesql @sql, N'@LocationID int', @LocationID;

This way you get a different plan when the parameter is included vs. when it is not, which doesn't really make the scan (where you need all rows) any better, but it guards against the case where you use a seek + lookup against all rows, which can be really bad. More often, it prevents you from getting the dreadful full table/index scan when you really could have used a seek. But which way that goes is completely dependent on which case is more likely the first time the query runs.

And even here you may want to use OPTION (RECOMPILE) at the end of @sql if the distribution of data across different LocationID values is (or might later become) heavily skewed.

I call this type of query "the kitchen sink," and have written about it here:

• #BackToBasics : An Updated "Kitchen Sink" Example

So the variable should be 1 or the locationid? You could use an IN for that.

... WHERE @LocationID IN (1, LocationID)

Example snippet:

declare @locationID int;

-- Test data using a table variable
declare @varTable table (id int identity(1,1) primary key, locationID int, name varchar(20), color varchar(10));
insert into @varTable (locationID, name, color) values  
(1,'Test 1','Blue'),
(2,'Test 2','Red'),
(1,'Test 3','Red'),
(2,'Test 4','Red'),
(3,'Test 5','Red');

-- Returning all records
set @locationID = 1;
SELECT t.* FROM @varTable t WHERE @locationID IN (1, t.locationID);

-- Only returning those with locationID = 2
set @locationID = 2;
SELECT t.* FROM @varTable t WHERE @locationID IN (1, t.locationID);