Tras abrir una traza con SQL Profiler una de las posibilidades que nos ofrece es la de exportarla a una tabla dentro de una base de datos de forma que podamos trabajar más cómodamente con ella. Hasta ahora nunca me había encontrado ningún problema en este proceso (aparte de la relativa lentitud). Sin embargo hoy al exportar una traza a tabla me he encontrado con este hermoso y explicativo error “Cursor operation conflict”:
Lo primero que pensé es que, de alguna forma, estaba interpretándose alguna de las operaciones de cursor que estaban presentes en la traza (lo cual no tenía mucho sentido). Para descartar esto probé con otra traza sencilla que tan solo contenía un “select * from sys.objects” y comprobé que seguía dando el mismo problema. Lo siguiente que probé fue de guardar la traza contra otra base de datos y obtuve el mismo resultado. Probé contra otra instancia y funcionó perfectamente. De esto se deducía que algo había mal con esta instancia en concreto. Al intentar recordar que había modificado últimamente en dicha instancia di con el problema.
Hace unos días para poder simular unos problemas de un cliente con cursores OLEDB necesité modificar las opciones por defecto del usuario para que por defecto NOCOUNT estuviera activado. Desgraciadamente no hice “rollback” de aquellas pruebas. Finalmente la solución pasó por volver a dejar las opciones por defecto del usuario tal cual vienen por defecto en el producto:
exec sp_configure ‘user options’,0
go
reconfigure
De nuevo vemos como muchas veces los errores son bastante oscuros y nos pueden volver un poco “locos” hasta dar con ellos y erradicarlos.
Happy tuning! J
