Nada mas frustrante que un bug dificil de solucionar y que te aparece justo antes de un roll out a producción, esta demas decirles que estas semanas he estado un poco desconectado debido a las cargas de trabajo, sin embargo me parecio una buena idea comentar algo de lo que acabo de vivir hace unos minutos, resulta que habiamos estado teniendo problemas con una applicacion que usa NHibernate, existen algunas tablas que ocupan referencias unicas a otras tablas y para llevar a cabo uan sincronización adecuada de los datos hacemos uso de cierta configuración en los mappings de NHibernate para salvar los objetos referenciados por otros en una misma transacción o simplemente para borrar la referencia 1:1 cuando ya no se ocupa, algo similar a esto :
<many-to-one name="_DireccionId" column="direccion_id" class="ITB.Contraloria.Business.Genericos.Entities.GenDireccion,ITB.Contraloria.Business.Genericos" cascade="all-delete-orphan"/>
el caso es que todos los módulos donde hacemos uso de esta técnica de salvado(multiple) funcionaban a la perfección , sin embargo desde ayer empezamos a tener comportamiento raro en uno de ellos el cual enviaba un error solo en la actualización cuya descripción era esta (Unexpected row count: 31; expected: 1), no existe mucha documentación al respecto asi que haciendo uso del profiler me percate de que no era ningún problema con la referencia hacia la tabla de actualización por cascada, el problema no se presentaba cuando habia una inserción de cero sino solamente cuando se hacia una actualización por lo que buscamos algún trigger que pudiera estar causando esto y efectivamente se trataba de esto, es decir, el problema no se debe a alguna actualizacioó en cascada que pudiera estar haciendo nhibernate de forma automática (dado que esta configurado asi y algunos objetos podrian tener los mismos identificadores) sino que el ROW COUNT manda una 'señal' erronea a nhibernate haciendole creer que se trata de un problema con la unicidad del registro lo cual es falso pues mas bien el ROW COUNT regresa el número de registros afectados por la ejecución de trigger y no el número de registros afectados por el update.
SOLUCION: desabilitar el trigger cuando se ejecute la sentecia de actulizacion proveniente de NHibernate.
IF EXISTS (SELECT * FROM sys.triggers
WHERE parent_class = 0 AND name = 'safety')
DROP TRIGGER safety ON DATABASE;
GO
CREATE TRIGGER safety
ON DATABASE
FOR DROP_TABLE, ALTER_TABLE
AS
PRINT 'You must disable Trigger "safety" to drop or alter tables!'
ROLLBACK;
GO
DISABLE TRIGGER safety ON DATABASE;
GO
Espero que esto les sea de ayuda y les ahorre algunas hrs de frustración.
PS, aqui pueden encontrar un post de un error similar en donde el trigger de una tabla evita la ejecucion de la sentencia de nhibernate.
http://community.countersoft.com/forums/thread/4167.aspx
