Possibility to deactivate row count checking
Description
Environment
Attachments
Activity
Mike,
Can you also add a wiki in our "How to wiki" ?
http://nhforge.org/wikis/howtonh/default.aspx
Thanks.
I wrote up my solution here http://stackoverflow.com/questions/1354362/toomanyrowsaffectedexception-with-encrypted-triggers/2698205#2698205 so that hopefully a few other people will find it.
I agree that you can close this issue.
We have also successfully worked around this problem using Fabio's solution. In our case we already had a custom driver so Fabio's approach of injecting the IBatcherFactory via the driver worked really well for us (http://groups.google.com/group/nhibernate-development/browse_thread/thread/56d959bedf6bc45).
Thank you. I've tried this and it works. This solves my problem in a much cleaner way than forking NHibernate or altering the 3rd party DB.
One small point: I had to completely reimplement SqlClientBatchingBatcher because the implementation of DoExecuteBatch is non-trivial. It uses some private member variables that are also used elsewhere in the class. I just copied the SqlClientBatchingBatcher as a whole and commented out the VerifyOutcomeBatched call. But all in all, an easy fix.
You can inject your IBatcherFactory implementation. Inside your batcher you can override DoExecuteBatch and avoid the call of VerifyOutcomeBatched.
The configuration property is : adonet.factory_class
Because the feature is there I think we can close this issue.
I'd like to suggest a new setting to deactivate checking of affected rows. To make it a little bit clearer, I want a possibility to deactivate the TooManyRowsAffectedException. In the project I'm involved we have hundreds of triggers that run inserts and updates oder deletes when queries are fired. In all cases I get the mentioned exception from NHibernate. SET ROWCOUNT OFF isn't a possibility in that case! So I had to comment out the lines throwing the exception in NHibernate.AdoNet.Expectations. I found that many people have the same problem, but with fewer triggers, so SET ROWCOUNT OFF was a way to go... I think, it would be better to provide a setting (perhaps in hibernate.cfg.xml) to deactivate the check for too many affected rows.