I'm sorry, obviously this post should be in "generated code"... I clicked too fast I guess

I have code like this:

try {

   unitOfWork.Commit( transaction ); 

   transaction.Commit();

            
} catch ( SD.LLBLGen.Pro.ORMSupportClasses.ORMQueryExecutionException ex ) {

    transaction.Rollback();

     // error messages and stuff...

}

Whenever an update (called by the unitOfWork) causes an ORMQueryExecutionException to be thrown it doesn't get "catched" by my code (at first), but instead the Visual Studio Exception Assistant pops up with the line causing the exception marked GREEN (instead of the usual yellow). This particular line is in the EntityBase class:

protected override bool InsertEntity()
{
    DienstboekDAO dao = (DienstboekDAO)CreateDAOInstance();
    return dao.AddNew(base.Fields, base.Transaction); // <--- this one causes the exception
}

But I can click "continue". When I do that my code catches the exception as it should and rolls back the transaction.

When I build my app with the "release solution config" it all works fine, but it is very annoying when debugging and I can't help but think that this should not be happening, so in other words, that I made a mistake somewhere.

To be clear: I expect the Exception to be thrown, because I was testing the rollback and error messages. So my question isn't about WHY the exception is thrown, I know that (I try to insert a duplicate primary key), but my question is; why does the exeption first get caught by the Exception Assistant and later by my own catch block?

I'm using Visual Studio 2005 (.NET 2.0) and SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll version 1.0.2005.1 with an Access database.

Please specify the RuntimeLibrary Version

SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll (right click) -> Properties -> Version -> File version

Thanks.

The file version of SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll is:

1.0.20051.051222

Could you add a catch(Exception ex) below your catch clause, and check what type 'ex' is ? Also, please upgrade to the latest build of the runtime libraries.

I wasn't aware there was a newer version. But I installed it, and checked if it got used, and it did.

Also, the type of the System.Exception is SD.LLBLGen.Pro.ORMSupportClasses.ORMQueryExecutionException

Also, even when I only catch the System.Exception it still fires the Exception Assistant first at the specified line...

So the exception IS of type ORMQueryExecutionException, but it's not caught by your catch rule? very strange... could be a version mismatch between two projects referencing different ormsupportclasses versions (so the type is different, i.e. from a different assembly) but then again, it's really weird.

I'm actually beginning to think that it's something not very much related to llblgen.

When I remove my try..catch entirely you would expect the Exception Assistant to kick in at the line unitOfWork.Commit( transaction );

But AGAIN first it shows the exception here:

return dao.AddNew(base.Fields, base.Transaction); // <--- this one

with a GREEN bar and than, when I click continue the Exception Assistants moves to my own code (unitOfWork.commit())

this line is selected with a YELLOW bar and I'm unable to click continue (offcourse)

So there seems to be a difference between the two types of exception "throwing" (the colors of the selections and the option to "ignore" the first.)

Like I said, when I complie with the "release" option it all workst fine, only in debug mode I get this weird behaviour.

Any ideas? Maybe it's a setting in my Visual Studio or something? I couldn't find nothing though..

very strange. That the release build works fine suggests that some data in the release build's output folder is more correct than in the debug folder. Is that the case in your application?