What works in 2008R2 is not working in 2012 SP1

Question

Setup:
Visual studio 2010 and 2012.
Database: both 2008R2 and 2012 SP1
Issue:
I have a CLR routine that does bulk update.
I have trigger on the tables that are being updated.
Using the same code and the same data, This bulk update query works in 2008, but does not work in 2012, WHEN there is more than one record to be updated.
My query is simply an update statement, updating table 1 from fields in table 2
I get no errors when I trace through it in Visual studio 2012, the data simply doesn't update.
However, if I run it in studio manager, I will get a range of errors, like, 'statement is terminated', or  that there was an error in the trigger, or that it completed successfully, but the data does not update.
Disabling and re-enabling the trigger works, but that's not a good idea, and since I have many bulk update queries (and have been plagued with issues for the sites that have updated to 2012), I need a solution.
Any one run into this?  Any ideas about what I can do?

Answer 1

Well, earlier you said:
sometimes I get 'the statement was terminated' (nothing else), or I get some error occurred in the trigger, or I get query completed, but the data did not update.
So there is some confusion about what exactly is occurring.  But without code, there is nothing to do but speculate.  Now you say that when there are multiple records that match the criteria it does not work.  I assume that your context here
is the update statement - when it updates multiple rows the trigger does not have the desired effect.  If that is not correct, it would help if you could clarify a specific (and hopefully simple) scenario for this case. 
But based on this information, it seems that the trigger may have an assumption built into it that is not appropriate.  A trigger does not execute for each row - it executes at the statement level and the virtual tables (inserted and deleted) can contain
any number of rows (from zero - yes, zero - to any number).  Often developers do not realize that the logic must be written to handle a variety of rows; rather they assume that only 1 row is present.  I would also suggest that perhaps a
similar assumption is made in the update statement you posted - but I don't know the relationship between the 2 tables (Invoice and Cust) so I could be wrong. Perhaps the update statement joins a customer to multiple invoices in some cases (rather than
an assumed 1 invoice per customer)? Perhaps there is some other oddity that is not evident from a distance.