Re: Violation of PRIMARY KEY constaint...
- From: "RobinS" <RobinS@xxxxxxxxxxxxxxx>
- Date: Thu, 29 Mar 2007 17:14:33 -0700
Most people use an identity column for their primary key.
What's killing you here is the SELECT COUNT. Your dataset tracks whether a
record is supposed to be inserted or updated. Do you think somebody is
going to come in and add the same record that the current user has added?
Is that really likely?
If you can rely on the dataset, you can set up an InsertCommand,
UpdateCommand, and DeleteCommand object for the data adapter, and the data
adapter will run the Insert command for Adds, and the Update command for
Changes and the DeleteCommand for deletes. You just call the Update method
of the TableAdapter once. It goes through the rows and processes them
accordingly.
Robin S.
-----------------------------
"Ken Abe" <KenAbe@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:34335C98-F0C1-4B6B-9AFA-721547EA2C71@xxxxxxxxxxxxxxxx
Thank you all for your input. Based on the assumption that
SqlCommandBuilder
is probably the culprit, I went a head an implement my own SP which
handles
both insert and update. It does a query on the two integers that make up
the
primary key and performs either an insert or an update accordingly:
if (select count(*) from t where key1 = @key1 and key2 = @key2) > 0
<update>
else
<insert>
All I achieved is to slow down the application. The Primary Key
constraint
violation still happens.
If aggregate primary keys are problematic, what's an alternative approach
to
solving this kind of problem, aside from not using ADO.net?
.
- Prev by Date: Concurrency Violation
- Next by Date: Re: Shameful design
- Previous by thread: Re: Violation of PRIMARY KEY constaint...
- Next by thread: Tabledefs and VB.net
- Index(es):
Relevant Pages
|
