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  

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Add comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading



IT Builder

Conoce mas de los servicios de IT Builder y la forma en la que podemos apoyarte a construir software de clase mundial

* Procesos para el desarrollo de software (CMMI, MSF, TSP, PSP, Moprosoft).
* Habilitacion de ambientes colaborativos y automatizacion con Visual Studio Team System.
* Arquitectura de aplicaciones bajo tecnologia Microsoft.
* Construccion de aplicaciones .NET.

www.itbuilder.com.mx
Imaginalo, nosotros lo construimos !

Calendar

«  February 2012  »
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
2728291234
567891011
View posts in large calendar

MVP

MVP Factor


Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2012 ITB - Gabriel Oliva C.