Gents....

It is with a sad and heavy heart that I admit I screwed up my view... LOL.. I fixed it and they give the same result...

Here ya go....

Lynn, Did you look at the video link I posted?

in the famous words of Homer Simpson...

D'OH! Ok... ...

SWEET!! OK.. Now we're getting somewhere...

Here's what I did. I put together some DDL so that I can see if the issue duplicates... and it...

Yes... you did.. but honestly, the posts were coming in so quickly, I coudldn't keep up...

I tweaked the query to take that into account with no change...

26666 records vs. 26672......

I'm not going to say your wrong. But I will say that I think the problem has been twisted and trounced that it's not even the same problem anymore.......

HOLY Recursive Statement Batman!!

I just noticed that the Joins don't have the NOLOCK hint, but the views all DO have the no lock hint.... so by switching to...

I'm getting really lost here.

I don't use the ISDELETED predicates in the where clause when I use the view. It's in the view so I don't need to.

The ISNULL(ISDELETED,0)=0 condition in the where clause is eliminated when the view is used, I don't even run it.

When I switch to the view, I comment out the where clause.

When...

Becuase I was switching back and forth between the view and the table. For the production version, once this annoying issue is resolved, the Where clause predicates referencing the...

Normally, the query uses the table... the ISDELETED column shows us that the record is no...

Something else.... The ISDELETED predicates are irrelevent in that all the tables are repointed to their corresponding view. Thus the ISDELETED is already in the statement.

'splain, Lucy...

Lynn Pettis (5/24/2012)

---

Actually, you didn't eliminate the NOLOCKS hint, you just hide them in the view.

What is with the hint any way? You do know the issues with using...