SqlCommand fails to throw exception on constraint violation

[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????

 

[Miha Markic]

Hi Alex,

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

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????

No, it just executes the sql statament.

 

[Alex Agranov]

You sure?

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

 

[Val Mazur]

Hi Alex,

Could you post code here that somebody could reproduce the problem?

 

[William Ryan]

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

 

[Miha Markic]

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.

LOL