Moguce je izvrsiti upit ako se zna tabela i bar jedno jedinstveno polje pored id-a, ali da li postoji neko elegantnije resenje u ms sql-u pored ovoga.

Pitanje ti nije baš najjasnije, ali ako si mislio na tabelu koja ima IDENTITY kolonu, pa hoćeš da saznaš posle INSERTA koja je vrednost dodeljena novunetom redu onda pročitaj u BOL-u teme vezane za:

IDENT_CURRENT returns the last identity value generated for a specific table in any session and any scope.


@@IDENTITY returns the last identity value generated for any table in the current session, across all scopes.


SCOPE_IDENTITY returns the last identity value generated for any table in the current session and the current scope.

I odaberi opciju koja tebi odgovara.

Tc, tc, tc.. neko je pametno uzeo identity za PK pa sad ima problem ;-)

Sta je lose u tome da identity bude primarni kljuc?

CREATE TABLE test ( ID identity PRIMARY KEY, Fname varchar(50), Lname varchar(50))

Mogu da unesem isti rekord jedno 10 puta i sistem to ne primeti, jer je zaboga sve u redu, svaki rekord lepo dobije svoj PK, koji je naravno identity i naravno ne znamo sta je dok ne procitamo SCOPE_IDENTITY():

INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')

Nema nista lose u koriscenju identity za PK, osim sto je protiv normalizacije i lako se zapadne u velike nevolje. Pogotovo za pocetnike je opasno, a nazalost je resenja vrlo privlacno. Uvedes identity PK i sve postane savrseno normalizovano naoko. Po definiciji, PK je jedan ili vise atributa koji jedinstveno odredjuje/odredjuju entitet. Pazi, entitet, a ne rekord u tabeli. Entitet postoji nezavisno od tabele i baze, postoji u realnom zivotu. Prema tome, PK za bilo koji entitet mora biti pozant PRE unosa u tabelu. Vrednost za identity NIJE poznata dok se INSERT ne izvrsi. Sledi da identity po definiciji ne moze biti PK. Identiti jedinstveno odredjuje rekord, a ne entitet. A u relacionim bazama ne radimo sa rekordima nego sa redovima (rows) koji odgovaraju entitetima

Necu dalje da raspravljem, to smo vec nekoliko put radili na bazama podataka i svako je ostao na svome. Ko voli nek izvoli i nek se nada da ce front end uhvatiti duplikate pre nego sto udju u bazu, jer identity to ne moze da uradi.

Duplikate mozes spreciti i preko unique indexa nad poljima, ukoliko je neophodno.
A ako ispravno dizajniras klijent, servis ili sta god sto koristi MSSQL , sigurno ti se nece desiti da zaboravis da menjas vrednosti parametara koje insertujes u tabelu :).

Sve ostalo ide u prilog tome da se uvek kao primary key koristi identity a ne GUID ili sta vec (human unreadable).

Pozdrav

podizem ovu temu da je razradimo jos malo
Ako unosim red i prepustim bazi da generise GUID (!!! - dakle ne identity, PK mi je GUID), kako da ga izvucem???
postoji li neka funkcija slicna scope_identity()... svak druga varijanta je prilicno nesrecna i traljava

hvala na brzom odgovoru (sedim u kancelariji i kucam proceduru, pa mi zapelo ) :-)

Pa generiši ga sam, pre nego što uradiš INSERT, i vrati ga. Sa GUID-ima je bar lako. Ako ne radiš sa stored procedurama, generiši GUID u kodu.

ok
znam za tu varijantu
ali polje UNIQUEIDENTIFIER moze imati default vrednost (NEWSEQUNTIALID()) koji vodi racuna da svaki novi guid ima vecu vrednost od do sada generisanih. TO je ok za PK, ali ne moze da se zove iz sproca.
mislim da je ipak mnogo elegantnije resenje da postoji neka funkcija tipa scope_identity(), nego da sam generisem
Ipak, tako za sada radim i radi
hvala