let's first try to get the data element names into ISO-11179 rules and write it in Standard SQL instead of local dialect.  Let's get the sdates into ISO-8601 format, too.  Since Data Entry date is physical meteadata, that column should be the posting date or some other logical data elemetn name.  Actuaqlly, if the version number is temporal then it is redudant. But ignoring that

CREATE TABLE People  -- tabls have co9llective names
(person_id INTEGER NOT NULL,
 version_nbr INTEGER NOT NULL,
  posting_date DATE NOT NULL,
 PRIMARY KEY (person_id, version_nbr));

INSERT INTO People VALUES
VALUES (1, 0, '2000-03-10'),
       (1, 1, '2000-03-16'),
       (1, 2, '2000-03-19'),
       (1, 3, '2000-03-18'),
       (1, 4, '2000-03-17'),
       (2, 0, '2000-02-10'),
       (2, 1, '2000-02-11'),
       (2, 2, '2000-02-18'),
       (3, 0, '2000-03-25'),
       (3, 1, '2000-03-23'),
       (3, 2, '2000-03-26'),
       (3, 3, '2000-03-30'),
       (4, 0, '2000-08-19'),
       (4, 1, '2000-08-20'),
       (4, 2, '2000-08-23'),
       (4, 3, '2000-08-24');

With the new functions, your query is fast and easy:

SELECT DISTINCT X.person_id, X.version_nbr, X.posting_date
  FROM (SELECT person_id, version_nbr, posting_date
               ROW_NUMBER()
               OVER (PARTITION BY person_id
                         ORDER BY version_nbr) As version_seq,
               ROW_NUMBER()
               OVER (PARTITION BY person_id
                         ORDER BY posting_date) As posting_seq
         FROM People) AS X
 WHERE X.version_seq <> X.posting_seq;

Thanks for posting a modified version.

Oh, be careful... the original code contains "qualified" Triangular Joins.  If you take a peek at the arrows in the execution plan, you'll find row counts of 107 and 66 to process just the 16 that are the original data.  For more on what a "Triangular Join" is, please see the following article...

 http://www.sqlservercentral.com/articles/T-SQL/61539/

[quote user="jcelko"]...With the new functions, your query is fast and easy:

SELECT DISTINCT X.person_id, X.version_nbr, X.posting_date
  FROM (SELECT person_id, version_nbr, posting_date
               ROW_NUMBER()
               OVER (PARTITION BY person_id
                         ORDER BY version_nbr) As version_seq,
               ROW_NUMBER()
               OVER (PARTITION BY person_id
                         ORDER BY posting_date) As posting_seq
         FROM People) AS X
 WHERE X.version_seq <> X.posting_seq;
[/quote] You seem to be solving a bit different problem, Consider the set of data:

INSERT INTO People VALUES
       (1, 1, '2099-01-01'),
       (1, 2, '2002-01-01'),
       (1, 3, '2003-01-01'),
       (1, 4, '2004-01-01'),
       (1, 5, '2005-01-01'),
       (1, 6, '2006-01-01'),
       (1, 7, '2007-01-01'),
       (1, 8, '2008-01-01'),
       (1, 9, '2009-01-01'),

Only first record is out of order according to the guy's requirement "the succeeding version’s Data Entry Date should be greater than its preceding version’s Data Entry Date.". All but the first record have succeeding version’s posting_date greater than its posting_date. But your query returns that all the records are out of order for that set of data.

Self joins seem to be a way to go for such kind of problems. "SQL Puzzles And Answers" by Joe Celko is incredible book on the subject. The only thing I'd like to add is that for really huge sets of data I would execute stored procedures page by page. Just remember current person_id and version_nbr between the executing the stored proc and handle only page_size (roughly) number of records per the execution.

Here is a self-join to get the rows out of order. 

select     p2.personid outoforderperson,p2.version outoforderver, p2.dedate outoforderdate,
    p1.personid inorderpers,p1.version inorderver, p1.dedate inorderdate

from person p1
join person p2
    on p1.personId = p2.personid and p1.version < p2.version and p1.dedate > p2.dedate

Pardon me if the format is screwy.  This is my first post to the site

Toni

 Or if you want just order based solely on the preceding id:

select     p2.personid outoforderperson,p2.version outoforderver, p2.dedate outoforderdate,
    p1.personid inorderpers,p1.version inorderver, p1.dedate inorderdate

from person p1
join person p2
    on p1.personId = p2.personid and p1.version = p2.version -1 and p1.dedate > p2.dedate

Toni

I don't see why a cross join was used here. If I change the CROSS JOIN to INNER JOIN, and change the WHERE clause to ON, I get the same query plan and hence same result.

 I rewrote it the following way. It is a different result than the original query because I want just the wrong versions flagged. If there are a great multitude of versions I would like to be able to see which specific version is wrong. Often times it would be better not to include columns like DEDate from the CTE (doesn't participate in the rowNum generation), but in this particular case it is preferable to leave it in since we have it "in hand" in the (clustered) index it is running over. I just guessed at how to handle null dates since it wasn't spelled out.

;with cte as
(SELECT
    PersonId
    ,Version
    ,DEDate
    ,rowNum=row_number() over (partition by personid order by version)
from Person
)
select
    a.PersonId
    ,a.Version
    ,a.DEDate
    ,OutOfOrder =
        case
            when b.PersonId is null then cast(0 as bit)
            when a.DEDate > isnull(b.DEDate, 0) then cast(1 as bit)           
            else 0
        end           
from cte as a
    left outer join cte as b on a.PersonId = b.PersonId
        and a.rowNum + 1 = b.rowNum