Nej, det finns ingen fördefinierad funktion i SQL Server som returnerar den "sista raden" i en tabell.
Per definition är en tabell en oordnad uppsättning rader. Föreställ dig att du kastar ett gäng kulor i en påse. Öppna nu påsen och fråga någon annan vilken marmor som gick i först eller sist. Kasta nu alla på golvet, och när någon annan kommer in i rummet, fråga dem vem som träffade golvet först eller sist. Du kan inte göra det, för det finns ingen ytterligare information som indikerar något om i vilken ordning de föll.
Detsamma gäller för en tabell i SQL Server. Såvida du inte lägger till en IDENTITY-kolumn, eller en datetime-kolumn eller en trigger, eller använder extern funktionalitet som ändringsspårning, CDC, revision, etc., finns det inget sätt för SQL Server att berätta vilken rad som infogades senast. Du kanske tänker att bara välja från tabellen utan en order by-sats looks som att det returnerar data i rätt ordning är detta en ren slump. Här är ett exempel:
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, så som standard verkar det här vara okej. Resultat:
ID n
-- -------
1 Sparky
2 Aaron
3 Norbert -- < yes, this is right
Men låt oss göra en förändring i tabellen som din ansökan eller vad som helst annat som bygger på ovanstående beställning inte har någon aning om:
CREATE NONCLUSTERED INDEX x ON dbo.floobat(n);
SELECT ID, n FROM dbo.floobat;
Hoppsan! Resultat:
ID n
-- -------
2 Aaron
3 Norbert
1 Sparky -- < oops, this is no longer right
Du måste komma ihåg detta:om du inte inkluderar en ORDER BY-klausul, är du berättar SQL Server som du inte bryr dig om beställning. Så det kommer att hitta det mest effektiva sättet att returnera data, och det kan leda till en annan observerad ordning. Att lägga till indexet ovan gav SQL Server en bättre åtkomstväg för att hämta data. Det använde fortfarande en skanning, men det indexet var mycket smalare än det klustrade indexet (som bara fick plats med två rader på en sida).
Även utan indexet skulle du förmodligen inte få de resultat du förväntade dig, eftersom det är förvirrat av det faktum att ditt Cust_ID kolumnen infogas inte i stigande ordning. Så om du infogar 5 och än 2 , om du väljer utan ORDER BY kommer det faktiskt att resultera i 2 sedan 5 (förutsatt att det inte finns något bättre index).
Andra saker än att skapa (eller ta bort, eller ändra eller bygga om) ett index kan orsaka samma typ av förändring i ordningsbeteende. Tillämpa ett service pack, CU eller snabbkorrigering; tömning av procedurens cache; använda olika RECOMPILE-alternativ; uppdatering av statistik; starta om servern; lägga till eller inaktivera en spårningsflagga; ändra ett serveralternativ; flytta databasen till en annan server; etc. etc.
Så om du vill spåra den här informationen måste du lägga till den själv på något sätt, vilket flera av de andra svaren har tagit upp.