I'm sorry you feel insulted. Despite what you may think, it was not my intention to do that. Please enlighten me. Which words in my replies do you consider an insult?
The notion of a "row" is a concept that certainly applies to a relational database. I never said anything about a "row". It was the concept of a "row number" that I was objecting to. Please reread what I said.
Believe me, I understand your question quite well; thank you for your concern. In fact, my prior comments clearly indicate that this question (or a variation) has been posted on this forum numerous times. Which means it has been answered many times.
This particular question, concerning SQL Server 2005, posted on an SQL Language
forum is particularly interesting because you have so far refused to accept that your question is meaningless without some context. Instead, you choose to complain when this is pointed out to you.
I'm honestly trying to help you understand why
what you've asked is meaningless. Despite your apparent thin skin, let me try to explain this again.
#1. SQL has no concept of a "row number". There is no such thing in a (true) relational database. Some implementations of SQL have extended the language, in a non-standard way, to include such a capability. Many would argue that defining such a concept flies in the face of the definition of what a relational database is. In any case, SQL Server isn't one of those implementations that has a "Row Number". I'm glad you were able to get an answer elsewhere. If the response included the use of a "row number", then it couldn't have been by using SQL Server.
#2. Rows in a relational database table are inherently unordered. The rows in a table in a relational database are members of a set
(in the mathematical sense), and as such, members of a set are unordered. The upshot of this is that the database is free to deliver the rows that satisfy your query in any order at all, absent any specific ordering via an ORDER BY clause. This is true even though a particular tool you may use appears to order the rows; in fact, the order is simply dependent on the query processor, and that will do whatever it wants (unless, of course, you or the tool specifically request an order via an ORDER BY clause).
#3. The concept of "last" implies an ordering of the rows of a table. If I have a jumble of paper clips in a pile on my desk, which one is the "last" one? Given #2 above, the concept of "last" is therefore meaningless unless some ordering is imposed (i.e. if I place all the paper clips in a line, I can identify the "last" one I put there).
I'm curious as to what your use of the word "last" means in the context of your particular situation.
The implication of point #2 above is that if you execute a query such as:
SELECT * FROM MyTable;
then there is no guarantee
that the rows will be presented in any particular order. The query processor is free to present the rows in any order it chooses.
Now, if you have a column value which imposes an ordering of some form, such as, say, "LastProcessedDate", then it's simple to find the "last" date by using the MAX aggregate function, assuming, of course, that by "last" you mean the latest date. Note that this might not actually be the very "last" entry in the table (which of course, has no meaning, see above), if the application allows some form of backdating. But that aside, retrieving the row that corresponds to that latest date can be obtained via a subquery:
SELECT * FROM MyTable
WHERE LastProcessedDate = (SELECT MAX(LastProcessedDate) FROM MyTable);
You might consider using an identity column to impose a form of ordering. Then you could use a similar subquery to retrieve the largest identity value:
SELECT * FROM MyTable
WHERE MyIdentityColumn = (SELECT MAX(MyIdentityColumn ) FROM MyTable);
This takes advantage of the fact that identity values are monotonically increasing. But, they don't have to be. It's quite possible (though perhaps unusual) to define a table where identity values actually decrease
(by setting the identity increment to a negative number). If that's the case, then the above will fail.
So you see, without knowing what it is you are trying to accomplish, and what data values you have in mind when you use the term "last", it is impossible to answer your question completely correctly.