giving error message according to Sql data
-
hey guys..i added a Unique constraint to a column in my sql table and if the user tries to add an existing data it gives error like that "Violation of UNIQUE KEY constraint 'ukc_cekilis_no'. Cannot insert duplicate key in object 'dbo.NumaraBilgileri'." it is ok..but i want to show an error message like that in my program..how i can check if the data already exist
-
hey guys..i added a Unique constraint to a column in my sql table and if the user tries to add an existing data it gives error like that "Violation of UNIQUE KEY constraint 'ukc_cekilis_no'. Cannot insert duplicate key in object 'dbo.NumaraBilgileri'." it is ok..but i want to show an error message like that in my program..how i can check if the data already exist
You could catch that particular exception. You could use a stored procedure to do the insert that checks first and returns a value that tells you what happened. A third option would be to query before you do the insert, but that is inefficient as you are making two trips to the database instead of just one.
-
You could catch that particular exception. You could use a stored procedure to do the insert that checks first and returns a value that tells you what happened. A third option would be to query before you do the insert, but that is inefficient as you are making two trips to the database instead of just one.
T M Gray wrote:
You could catch that particular exception.
Exceptions are for unexpected events not for normal processing.
I know the language. I've read a book. - _Madmatt
-
T M Gray wrote:
You could catch that particular exception.
Exceptions are for unexpected events not for normal processing.
I know the language. I've read a book. - _Madmatt
If that were strictly true then there would be no throw method. There would also be no need for subclasses of Exception. If you know what type of Exception to expect then it isn't an unexpected event. The answers I gave are factually correct. Your statement is a matter of philosophy or preference.
-
If that were strictly true then there would be no throw method. There would also be no need for subclasses of Exception. If you know what type of Exception to expect then it isn't an unexpected event. The answers I gave are factually correct. Your statement is a matter of philosophy or preference.
T M Gray wrote:
Your statement is a matter of philosophy or preference.
No, established best practices, architecture guidance and experience. http://msdn.microsoft.com/en-us/library/seyhszts.aspx[^] "Know when to set up a try/catch block. For example, you can programmatically check for a condition that is likely to occur without using exception handling. In other situations, using exception handling to catch an error condition is appropriate." In this case the unique key violation is a known condition that may occur and can be tested for.
I know the language. I've read a book. - _Madmatt
-
T M Gray wrote:
Your statement is a matter of philosophy or preference.
No, established best practices, architecture guidance and experience. http://msdn.microsoft.com/en-us/library/seyhszts.aspx[^] "Know when to set up a try/catch block. For example, you can programmatically check for a condition that is likely to occur without using exception handling. In other situations, using exception handling to catch an error condition is appropriate." In this case the unique key violation is a known condition that may occur and can be tested for.
I know the language. I've read a book. - _Madmatt
But do you know why it is bad practice? My point is that you shouldn't do something a certain way just because someone says so (even if that someone is Microsoft). Nothing in that article explains why you shouldn't use exceptions for program flow. If you had posted this[^] instead, that at least gives reasons related to performance. There should be real reasons behind why you code a certain way. If the original poster is not strong in SQL and has no method of source control for database schema then using the stored procedure solution makes it less maintainable. That probably outweighs the performance impact of the Exception use in one method of a small application. Blindly following a "best practice" without considering the specific situation is a bad idea. Consider this case[^] where it is a choice of one exception or 4 database roundtrips. Avoid dogma in code.
-
But do you know why it is bad practice? My point is that you shouldn't do something a certain way just because someone says so (even if that someone is Microsoft). Nothing in that article explains why you shouldn't use exceptions for program flow. If you had posted this[^] instead, that at least gives reasons related to performance. There should be real reasons behind why you code a certain way. If the original poster is not strong in SQL and has no method of source control for database schema then using the stored procedure solution makes it less maintainable. That probably outweighs the performance impact of the Exception use in one method of a small application. Blindly following a "best practice" without considering the specific situation is a bad idea. Consider this case[^] where it is a choice of one exception or 4 database roundtrips. Avoid dogma in code.
T M Gray wrote:
But do you know why it is bad practice?
Do you? Basically your arguments have no merit and are the ramblings of one uneducated in Software Engineering or Software Design principles. Further debate would solve no purpose against such an unprepared person.
I know the language. I've read a book. - _Madmatt
-
T M Gray wrote:
But do you know why it is bad practice?
Do you? Basically your arguments have no merit and are the ramblings of one uneducated in Software Engineering or Software Design principles. Further debate would solve no purpose against such an unprepared person.
I know the language. I've read a book. - _Madmatt
-
T M Gray wrote:
You could catch that particular exception.
Exceptions are for unexpected events not for normal processing.
I know the language. I've read a book. - _Madmatt
Uhm, his suggestion sounds pretty good to me. try { // code that attempts an insert } catch ( some exception) { // show error message to the user about how that key exists } What's the big deal?
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Uhm, his suggestion sounds pretty good to me. try { // code that attempts an insert } catch ( some exception) { // show error message to the user about how that key exists } What's the big deal?
Regards, Nish
My technology blog: voidnish.wordpress.com
I have always been taught and follow the principle that conditions that can be tested for are not exceptions and you shouldn't use exception handling for them. Certainly there are cases you can't test for or don't expect to happen. In this particular case the unique key violation is expected and can be tested for.
I know the language. I've read a book. - _Madmatt
-
T M Gray wrote:
Your statement is a matter of philosophy or preference.
No, established best practices, architecture guidance and experience. http://msdn.microsoft.com/en-us/library/seyhszts.aspx[^] "Know when to set up a try/catch block. For example, you can programmatically check for a condition that is likely to occur without using exception handling. In other situations, using exception handling to catch an error condition is appropriate." In this case the unique key violation is a known condition that may occur and can be tested for.
I know the language. I've read a book. - _Madmatt
Mark Nischalke wrote:
In this case the unique key violation is a known condition that may occur and can be tested for.
Every constraint defined on that table is known. Data-types and length, custom constraints, keys. A little further down on the page you're quoting from;
Microsoft wrote:
The method you choose depends on how often you expect the event to occur. If the event is truly exceptional and is an error (such as an unexpected end-of-file), using exception handling is better because less code is executed in the normal case.
It becomes philosophy again when you try to define "truly exceptional".
I are Troll :suss:
-
I have always been taught and follow the principle that conditions that can be tested for are not exceptions and you shouldn't use exception handling for them. Certainly there are cases you can't test for or don't expect to happen. In this particular case the unique key violation is expected and can be tested for.
I know the language. I've read a book. - _Madmatt
Mark Nischalke wrote:
I have always been taught and follow the principle that conditions that can be tested for are not exceptions and you shouldn't use exception handling for them. Certainly there are cases you can't test for or don't expect to happen. In this particular case the unique key violation is expected and can be tested for.
If this collision is a rarely occurring one or even an infrequently occurring one, I'd always just go ahead and try and insert and then catch any exception. I wouldn't run an extra database trip just to avoid catching an exception so my code is compatible with somebody's idea of a perfect design.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Mark Nischalke wrote:
I have always been taught and follow the principle that conditions that can be tested for are not exceptions and you shouldn't use exception handling for them. Certainly there are cases you can't test for or don't expect to happen. In this particular case the unique key violation is expected and can be tested for.
If this collision is a rarely occurring one or even an infrequently occurring one, I'd always just go ahead and try and insert and then catch any exception. I wouldn't run an extra database trip just to avoid catching an exception so my code is compatible with somebody's idea of a perfect design.
Regards, Nish
My technology blog: voidnish.wordpress.com
Yes, hence my statement, "cases you can't test for or don't expect to happen", I should have added, or happen often.
I know the language. I've read a book. - _Madmatt
-
Uhm, his suggestion sounds pretty good to me. try { // code that attempts an insert } catch ( some exception) { // show error message to the user about how that key exists } What's the big deal?
Regards, Nish
My technology blog: voidnish.wordpress.com
I'm not sure, but doesn't Sql Server throw a SqlException in these cases? The catch-all could hide conversion-errors, or index-out-of-bounds exceptions. It's still best to try to be specific about the type of exception that you're trying to handle.
I are Troll :suss:
-
If that were strictly true then there would be no throw method. There would also be no need for subclasses of Exception. If you know what type of Exception to expect then it isn't an unexpected event. The answers I gave are factually correct. Your statement is a matter of philosophy or preference.
I believe Mark's argument is that, given that the described error condition is a likely occurrence, then the OP should code to detect and handle the condition directly, rather than rely on the exception mechanism (which is expensive).
Software Zen:
delete this; -
I'm not sure, but doesn't Sql Server throw a SqlException in these cases? The catch-all could hide conversion-errors, or index-out-of-bounds exceptions. It's still best to try to be specific about the type of exception that you're trying to handle.
I are Troll :suss:
Yes only a SqlException is thrown, then you look at the number to determined the type of underlying Exception
I know the language. I've read a book. - _Madmatt
-
Yes, hence my statement, "cases you can't test for or don't expect to happen", I should have added, or happen often.
I know the language. I've read a book. - _Madmatt
Okay. But why did you pick on the guy like this? He gave 3 alternate solutions, only one of which suggested catching the database exception. It seemed as if you were looking for a fight here :-)
Regards, Nish
My technology blog: voidnish.wordpress.com
-
I'm not sure, but doesn't Sql Server throw a SqlException in these cases? The catch-all could hide conversion-errors, or index-out-of-bounds exceptions. It's still best to try to be specific about the type of exception that you're trying to handle.
I are Troll :suss:
Eddy Vluggen wrote:
I'm not sure, but doesn't Sql Server throw a SqlException in these cases? The catch-all could hide conversion-errors, or index-out-of-bounds exceptions.
Yeah, no one here has recommended a catch-all. What was recommended was to catch the specific exception thrown (which depends on what mechanism you are using to talk to the database). My take on this is that there are no hard and fast rules for things like this. In general, I just try and stick to some consistent practices on a project and these practices themselves may not be identical across multiple projects.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
I have always been taught and follow the principle that conditions that can be tested for are not exceptions and you shouldn't use exception handling for them. Certainly there are cases you can't test for or don't expect to happen. In this particular case the unique key violation is expected and can be tested for.
I know the language. I've read a book. - _Madmatt
In principal you are correct. But remember that exceptions are there for exceptional cases; pun intented. In the case of creating a new record where you expect the key to be unique, I agree with the others that using an exception is the correct approach. If there is a good chance that the key will not be unique then a different approach would be justified. There I would try to read the record with the key, if it does not exist then I would do the insert. I would however still have the try/catch on the insert.
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
-
Eddy Vluggen wrote:
I'm not sure, but doesn't Sql Server throw a SqlException in these cases? The catch-all could hide conversion-errors, or index-out-of-bounds exceptions.
Yeah, no one here has recommended a catch-all. What was recommended was to catch the specific exception thrown (which depends on what mechanism you are using to talk to the database). My take on this is that there are no hard and fast rules for things like this. In general, I just try and stick to some consistent practices on a project and these practices themselves may not be identical across multiple projects.
Regards, Nish
My technology blog: voidnish.wordpress.com
Nishant Sivakumar wrote:
Yeah, no one here has recommended a catch-all
Sorry, I get religious when I see one of those - it comes close to an "on whatevererror resume here".
Nishant Sivakumar wrote:
My take on this is that there are no hard and fast rules for things like this
There's this article on CodeProject[^] that seems to suggest that it wouldn't cost much in terms of performance. An exception that gets eaten OTOH, might be very costly.
Nishant Sivakumar wrote:
I just try and stick to some consistent practices on a project and these practices themselves may not be identical across multiple projects.
True. Hell, I'll even color-code the exceptions if there's a compelling reason :)
I are Troll :suss: