You can change collation for this particular column.

> But, even you, my old friend, are still saying the OR "will let SQL Server to use index if there is one". The real fact of the matter...

What?

Then what is that:

AND p.Rqrd = t.TypeId ?

It's clear join.

And this kind of WHERE clause eliminates any chance of NULL values coming from either table.

So, you can replace CROSS JOIN...

Jeff, the same way I can easily proof that walking is faster than driving a car. I just need to build special scenario for this.

Your point is not about query,...

There is an easier way.

Turn on Profiler, do whatever you wamt to do manually in EM, copy SQL commands executed by EM from Profiler to QA and slightly modify them...

Only if you don't use index.

Or half of values in the column = NULL.

In my experience it ALWAYS dramatically decreases execution time.

WHERE (T1.Col1 >= @date OR T1.Col1 IS NULL)

You must create both view and SP using it ON REMOTE SERVER.

And then just call it from here.

Why nobody mentioned query hints yet?

And if you use more than 10% of rows in table (either for join or to return in resultset) there is no point to use...

Who told you such cr.p about views?

If you do it right view is more efficient than query in SP.

So, you SP is just single SELECT?

That's why you came up with idea of COUNT(*) from SP.

To encapsulate complex joins you must use VIEWs, not SPs.

Then your SP will become...

So what?

What you gonna do if there are some employees?

Pass the resultset to application?

And if there are no employees you won't pass anything but several bytes overhead for empty recordset.

So, you are adding extra call for SP just to count rows in recordset?

Your company spent too much money on server and now you need to make it occupied?

Don't you...

So, if you don't use actual data returned by sp_GetAllEmployees, why you need this SP at all?

Why you need this SP if you don't use its result?