>Now it would be a great if you could deliver the equivalent of the SQL solution I provided to you in the other post, but with the USE of the RANK() function in SQL2005.
>
>Well let me help you.... There are a number of ways to do it, but one of them would be:
>
>These are the kind of problems that were not ment to be solved by SET ORIENTED approaches anyways, but still whole tribes of developers are doing this because the holy book promotes SET ORIENTED, sigh...
>
>a) I don't need any of your help.

Hmmmm, I was afraid, you would not answer as did happen twice before when I presented you with a question you could not answer, so I thought I'd help you out with an example of a PURE set-oriented approach.

>b) I wrote a solution that basically utilizes Common Table Expressions and a table-valued UDF. I'm posting it on my blog tonight and I'll post here when it's up. It is not as complex as you made it out to be, in your SQL query.

I'm anxious to see and comment on it, but since your blogg is not accesible at this time. I can only guess your solution is not a PURE set-oriented solution.

>c) Your conclusion says less about the capabilities of T-SQL and more about your level of experience with them.

ROFLMOA. TSQL <> SET ORIENTED. To the contruary my dear friend, I base my conclusions on the knowledge what SET ORIENTED and RECORD ORIENTED means, what their advantages and disadvantages are: Their applications. You base your conclusions on anedotical experience with what you define as 'Best practises' (e.g. SP discussions?) while actually having no clue about the underlying theory (e.g. Relation model, its SQL implementation, hierarchical databases) and how they should be practised. You keep focussing on one specific implementation of a RDBMS (SQL server) and expect that conclusions of propriatory implementations would apply to the whole world outside. Just ignore the MySQL, ORACLE, DB2 world outside huh? Who really cares about the exact definition of SET vs RECORD oriented? Lets say that T-SQL is SET ORIENTED and just for my convinience ignore that it contains certain RECORD ORIENTED functions in there, just to solve those problems which are difficult to do with a SET ORIENTED approach.

Kevin, you might think that you're a big boy in database world, but I've seen you make such ignorant, narrow minded and demonstratibly wrong statements over the last year or so (I suspect in your defense of having to use SQL server for your .NET applications, which clarifies your motives), that I don't have a particular high opinion of your overall knowledge of database systems. You have a LOT to learn in this respect.

OTOH, I've got to recognize that there are a lot of people like you, really having no idea about the differences in this respect. Since most of them will never or seldomly be challenged in this arena it does not make a lot of difference to them. The client would not know, whether something can be done more efficiently in a record oriented approach. Just throw in some extra hardware to solve the problem.

And no, my experience goes way beyond VFPs SQL and x-base implementation. I've dealt with SQL server and ORACLE for over 15 years and graduated on the subject or RELATIONAL DATABASE systems using codd's and date's literature as foundation. I know what I'm talking about.

Walter,