Probaj sa nekim SELECT upitom da proveris da li vec taj podatak postoji, ako vec postoji ne radi nista(ili prikazi poruku da podatak vec postoji) ako ne postoji(odosno rezulta upita je 0) onda radi INSERT.

Moze nesto ovako:

Obratite paznju na transakcionu izolaciju ako je neophodno. Ukoliko se ta procedura cesto poziva, a narocito u multi-user sistemima neophodno je odrzati lock izmedlju select i insert jer dva procesa mogu da udju u select i vrate o rows i da onda oba ulete u insert.

Moze nad tabelom da kreiras Unique Key i da baza sama stiti sebe

ALTER TABLE [dbo].[Tabela] ADD CONSTRAINT [IX_Tabela] UNIQUE NONCLUSTERED
(
[Name] ASC
) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY]

Ako vec 'Name' mora da bude jedinstveno, pitam se, pitam se, kako izgleda i cemu sluzi postojeci PRIMARY KEY? Vreme koje cete sada utrositi da resite problem sprecavanja unosa duplikata, bice mnogo duze, nego da ste pokusali da razumno definisete PK. I ako resite problem nekako, proverom na front endu, bas za svaki unos, osta je onaj problem sto je spomenuo mmix, a koji je veoma neugodan za resavanje. Toliko je neugodan da pametni ljudi ucine sve da do toga uopste ne dodje. Nekako kao "dilama je a) leciti ili b) uopste ne dobiti AIDS ili sifilis".

A posle svega, uvek ostaje mogucnost da neko uradi bulk inserst, pa resenje na front endu nece pomoci.....

Cesta je promena zahteva, pa se zbog toga traze alternativna i ne bas najbolja resenja. Service not a project...