ho le persone viste hanno problemi di progettazione con questa logica.
1 - Verificare l'esistenza del record.
2 - Se non esiste, inserire il record.
Specialmente se entra in gioco la concorrenza. A seconda del livello di isolamento, potresti avere dati duplicati o violazioni delle chiavi.
Perché non inserire una chiave primaria su pname e pnumber in primo luogo. Suppongo che tu stia parlando di un tavolo per persone.
Il mio esempio.
--
-- Setup sample table w/data
--
-- Sample table
create table #person
(
person_id int identity (1, 1),
person_name varchar(64) not null,
person_no varchar(16) not null
);
go
-- primary key
alter table #person
add primary key (person_no, person_name)
go
-- first insert works
insert into #person (person_name, person_no) values ('bilbo', 123)
go
La chiave della soluzione è intercettare la violazione della chiave primaria. Ignorare questo errore potrebbe essere un aspetto positivo o negativo a seconda della logica aziendale.
Ho deciso di ignorare il problema.
--
-- Ignore primary key violations
--
-- Try these steps
BEGIN TRY
-- Second insert fails
insert into #person (person_name, person_no) values ('bilbo', 123)
END TRY
-- Error Handler
BEGIN CATCH
-- Ignore PK error
IF ERROR_NUMBER() <> 2627
SELECT
ERROR_NUMBER() AS ErrorNumber
,ERROR_SEVERITY() AS ErrorSeverity
,ERROR_STATE() AS ErrorState
,ERROR_PROCEDURE() AS ErrorProcedure
,ERROR_LINE() AS ErrorLine
,ERROR_MESSAGE() AS ErrorMessage;
END CATCH
Questa soluzione elimina le voci duplicate e non segnala violazioni PK.
fonte
2013-10-10 17:52:54
Qual è lo scopo di questo controllo? Se stai verificando l'unicità, un indice univoco sulle colonne è più semplice. – podiluska