No, there is no predefined function in SQL Server which will return the "last row" of a table.
By definition, a table is an unordered set of rows. Imagine you throw a bunch of marbles in a bag. Now open the bag and ask someone else which marble went in first or last. Now throw them all on the floor, and when someone else comes in the room, ask them which hit the floor first or last. You can't do it, because there is no additional information that indicates anything about the order in which they fell.
The same is true for a table in SQL Server. Unless you add an IDENTITY column, or a datetime column, or a trigger, or use external functionality like change tracking, CDC, auditing, etc., there is no way for SQL Server to tell you which row was inserted last. You may think that just selecting from the table without an order by clause looks like it is returning data in the right order, this is pure coincidence. Here is an example:
CREATE TABLE dbo.floobat
(
ID INT PRIMARY KEY,
n VARCHAR(16),
x CHAR(4000) NOT NULL DEFAULT ''
);
INSERT dbo.floobat(ID,n) VALUES(1,'Sparky');
INSERT dbo.floobat(ID,n) VALUES(2,'Aaron');
INSERT dbo.floobat(ID,n) VALUES(3,'Norbert'); -- <-- inserted last
SELECT ID, n FROM dbo.floobat;
Ok, so by default, this seems to be okay. Results:
ID n
-- -------
1 Sparky
2 Aaron
3 Norbert -- < yes, this is right
However, let's make a change to the table that your application or whatever else relies on the above ordering will have no idea about:
CREATE NONCLUSTERED INDEX x ON dbo.floobat(n);
SELECT ID, n FROM dbo.floobat;
Uh oh! Results:
ID n
-- -------
2 Aaron
3 Norbert
1 Sparky -- < oops, this is no longer right
You have to remember this: if you don't include an ORDER BY clause, you are telling SQL Server that you don't care about order. So it is going to find the most efficient way to return the data, and that could lead to different observed ordering. Adding the index above gave SQL Server a better access path to retrieving the data. It still used a scan, but that index was way skinnier than the clustered index (which could only fit two rows on a page).
Even without the index, you probably wouldn't get the results you expect, since it is convoluted by the fact that your Cust_ID column is not being inserted in ascending order. So if you insert 5 and than 2, selecting without an ORDER BY will actually result in 2 then 5 (assuming no better index exists).
Other things other than creating (or dropping, or changing, or rebuilding) an index can cause the same sort of change in ordering behavior. Apply a service pack, CU or hotfix; flushing the procedure cache; using various RECOMPILE options; updating statistics; restarting the server; adding or disabling a trace flag; changing a server option options; moving the database to a different server; etc. etc.
So, if you want to track this information, you'll need to add it yourself in some way, as several of the other answers have addressed.
