I think you can eliminate the problem, and a full table scan, like below.

Whiile this makes your initial q moot for this specific example, it could naturally still be good...

ChrisM@home (1/29/2013)

---

GilaMonster (1/29/2013)

---

ChrisM@Work (1/29/2013)

---

How many rows in the table? How many rows are you returning? If you are returning more than say 25%* of the rows in the table, SQL...

PiMané (1/29/2013)

---

It has many more queries over other columns but I'll check the DMV for the most used indexes and see the one that's best for cluster since the actual...

The real key to performance is the proper clustered index.

If you (almost) always query [dbo].[XmlDataModel] by [ExerciseYear], then cluster by [ExerciseYear] followed by any other column(s) you (almost) always query...

Not 100%, as I don't have any table definition to look at.

But if fromdate and todate are both in the text format above, then something like:

SELECT

...other_columns...

...

select

convert(varchar(20), cast(stuff(substring(string, 5, 15), CHARINDEX(':', substring(string, 5, 15)) - 3, 0, RIGHT(string, 5)) as datetime), 120)

from (

select 'Mon...

Igor Makedon (1/28/2013)

---

Fine!

Are the folowing two SELECT statements equvalent (i.e. -- see my original question, -- "return exactly the same row set" no matter "what data is")?

[font="Courier New"]SELECT xx FROM...

WHERE and HAVING are fundamentally different; they should never be thought of as equivalent or interchangeable. That is, for a given query/subquery, only one of them is right to...

Bhuvnesh (1/28/2013)

---

if exists (select 1 from sysobjects where name = 'getNotificateProduct')

DROP PROCEDURE [dbo].[getNotificateProduct]

GO

Create PROCEDURE [dbo].[getNotificateProduct]

(

)

begin

....

....

end

IS...

SQL will tell you if/why it won't shrink the log:

SELECT log_reuse_wait_desc, * --col name may be a little off, from memory, but it's at least close

FROM sys.databases

WHERE name = 'yourDbName'

Nope, you have to synonym every object:

[LiveServer].[Databade].[TheSchema].[ObjectName1] --> [DevServer].[Databade].[TheSchema].[ObjectName1]

[LiveServer].[Databade].[TheSchema].[ObjectName2] --> [DevServer].[Databade].[TheSchema].[ObjectName2]

etc.

The only real "success" is for the 3rd party hack cashing the checks. Anyone trying to implement or maintain this system is, as "The Big Bang Theory" put it,...

Jeff Moden (1/28/2013)

---

My personal opinion is that if you're not going to persist a calculated column, write a derived table or view, instead. That way, no one can screw...

Just curious:

How did you determine that the deadlocking was due to FK lookups?

Legitimate FKs should be used when possible. FK definitions in SQL itself are vastly more efficient...

ScottPletcher (1/25/2013)

---

MyDoggieJessie (1/25/2013)

---

And Yes, changing the job name itself would still cause an issue, however hopefully changes like that would be made by a DBA or otherwise communicated that a...