SQL Server 2012:discrepancias de DATETIME entre inserciones y disparadores

Debido a la naturaleza declarativa de SQL, el motor de la base de datos podría tómese la libertad de evaluar partes de una instrucción SQL en el orden que crea conveniente (siempre y cuando no afecte la semántica). Su sugerencia de que GETUTCDATE() podría estar en caché, es plausible.

Sé que esto no responde a tu pregunta. Pero sea cual sea la implementación de GETUTCDATE en SQL2012, bien podría cambiar en una versión futura. Así que evite confiar en él, o las actualizaciones futuras podrían convertirse en un verdadero dolor de cabeza. Implemente su lógica de una manera que no dependa de ninguna suposición con respecto al orden de evaluación.

En su caso específico, veo algunas soluciones posibles.

1. Si no tiene ningún problema con OwningStatuses tener un tiempo un poco más tarde que UserStatusesHistory , entonces podría ser útil enviar el tercer paso a SQL Server como un lote separado.
2. Cambie los pasos 2 y 3; y deje que el activador consulte OwningStatuses en lugar de inventar su propia fecha.
3. Deje de usar factores desencadenantes; hay más de una razón para considerar esto.