Thanks for the reply. I'm not sure about a string method, I'll re-run my tests and see. For now we've decided that we can't risk the project with too much more research in this, and seeing as how the stored proc check works, we're going with it (though like I said, it just feels wrong :( Thanks again.
Have A Better One! John Deal -----Original Message----- From: Nick Wienholt [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 6:31 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Duplicate Keys Throwing System.ExecutionEngineException Is there a string method (something like String.CompareOrdinal) at the top of the stack when the ExecutionEngineException is thrown? I had a somewhat similar problem with duplicate keys in a NameObjectCollection-derived class throwing ExecutionEngineExceptions. As the ExecutionEngineException toasts the entire process, there isn't much you can do. The stored proc that does a check for duplicates sounds like the best solution. Nick Wienholt Sydney Deep .NET User Group www.sdnug.org ----- Original Message ----- From: "DEAL John M" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 25, 2002 1:16 AM Subject: [ADVANCED-DOTNET] Duplicate Keys Throwing System.ExecutionEngineException > We have run into something kind of bizarre with an application that > we're developing against a DB2 backend. What we are encountering > appears to be three different outcomes when we insert duplicate rows > (e.g. rows that violate primary key constraints) into a table. > > For example, in one table we enter a duplicate row and we get the > proper exception stating that we have violated the primary key, while > in a second table we get a message from ADO.Net (not our code) that it > has an object reference that has not been set, and in a third table we > get a System.ExecutionEngineException that crashes the application. > In the last situation we have setup try/catch blocks around > everything, but it doesn't help, it's like something core to the > runtime is crashing rather than our application (in fact we only know > about the exception type because of the dialog that the runtime pops > open before our app crashes). > > We have worked with our resident DB2 DBA on this, and he says that his > database traces show that the database is receiving our sql, that it > is correct, and that the database responds with the exact same result > codes and messages back to our application in all three instances. > Because of these results he is convinced that it is our application > causing the problem not the database, which also means that he isn't > real willing to further investigate it from his side. > > To fix this we ended up coding our stored procedures to check for > duplicates prior to inserting the record, returning a custom return > code and message if something went wrong, but that just feels wrong. > Has anyone else out there encountered this type of behavior, or for > that matter these exceptions that can not be trapped? If so, what > suggestions do you have for handling it? > > I know this is a bit long winded, so my thanks go out to anyone who > made it to the end, and my appreciation to any who can comment on or > give some suggestions. > > Have A Better One! > > John Deal > > You can read messages from the Advanced DOTNET archive, unsubscribe > from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
