SqlCommand fails to throw exception on constraint violation

  • Thread starter Thread starter Alex Agranov
  • Start date Start date
A

Alex Agranov

When I execute an UPDATE SqlCommand.ExecuteNonQuery() against a table that
has a foreign key constraint, ADO.NET fails to raise a SqlException.

I know that the constraint works, because if I try to update the table
through Query Analyzer or Ent Mangager, I get the appropriate error there.
Is ADO.NET disabling the constraint????
 
Hi Alex,


Alex Agranov said:
When I execute an UPDATE SqlCommand.ExecuteNonQuery() against a table that
has a foreign key constraint, ADO.NET fails to raise a SqlException.
Click to expand...

You sure?

I know that the constraint works, because if I try to update the table
through Query Analyzer or Ent Mangager, I get the appropriate error there.
Is ADO.NET disabling the constraint????
Click to expand...

No, it just executes the sql statament.
 
Miha said:
You sure?
Click to expand...

Yes I am, because I surrounded the ExecuteNonQuery() in a try/catch block,
with SqlException as the catch parameter. No exception was caught.
 
Alex:

Are you using a Stored Proc? Unless this is a weird bug, and I mean really
really weird, than I would guess that your query is either not returning the
exception correctly or another catch block is catching it, like a null
reference or something. Is the whole block just executing OK? If so, (I
know, but you have to ask these questions), are you sure the ADO.NET query
isn't executing correctly, but once the data is added and you verify it,
it's already in there hence raising the exception?

If you are sure it's none of these, then intentionally blow up the query.
I don't mean with a Key violation, but pass "BreakMe" into a DateTime
field, or something that you are positive the Server could never accept.
Then see if the Exception is raised.

I'd also add a System. Exception block underneath the SqlException Block.
If you hit a null reference for instance, it may blow up before ever being
executed, and propogate up the stack.

If you are sure off all of this, then please, show the SQL. You could be
returning a legit value instead of raising and error in the proc (if you
are using a proc) which may be obscuring it.

ADO.NET is really good, and i've got a couple of zillion queries worth of
time spent with her... and she's not afraid to talk when I mess up.

HTH,

Bill
 
Back
Top