usas SQL Profiler?
Básico, en un ambiente de desarrollo y parece que en mantenimiento también. Siempre ante cualquier marcianada que suceda en la aplicación, como por ejemplo, que has hecho una paginación optimizada, pero no se muestra data :S. En esos casos, mi última opción es depurar la aplicación. La primera opción es sacarla al "ojo" :D, al muy estilo de algunos retos de programancia101.
Si tienes una solución con unos cuantos proyectos, no cuesta nada depurar. Pero si tienes una solución un poco más compleja en capas, y con varios módulos. La opción de depuración se pone un poco más pesadita. Imagina que ya terminaste de hacer todas tus capas de componentes, y terminaste la capa final de presentación, pero por cuestiones del destino tu GridView con paginación optimizada no funciona. Entonces te echas a depurar esperas que compile, que cargue el navegador, empiezas a depurar, y aunque uses el QuickWatch de Visual Studio, tienes que irte hasta la última capa, para darte cuenta que te faltaba un parámetro, que hiciste mal una conversión, que un dato iba un null, y todo lo que normalmente pasa, si no, que levanten la mano los que han depurado y se encontraron que por copiar procesos, se olvidaron de cambiar el nombre del SPs, hasta el copy/paste hay que saberlo hacer :).
Pero como hacemos para aproximarnos a una depuración al "ojo"?. En un anterior proyecto en 3Dev, me inculcaron el uso de SQL Profiler, y bueno actualmente es imposible dejar de usarlo. Sobretodo si quieres ahorrarte tiempo y esfuerzo para ubicar el problema. Pero, que se puede hacer con SQL Profiler?, en cuanto a cosas básicas para depurar:
- Ver si se ejecuto o no la llamada a un StoreProcedure.
- Ver los valores de los parámetros de un StoreProcedure.
- Verificar la consulta generada en el Management Studio.
- Ver las llamadas que hace tu app al SQL.
- Y otras cosas más.
Algunas pantallazos:

En la pantalla superior podemos apreciar que efectivamente, se llegaron a realizar las llamadas a los SPs, y no se quedo en la aplicación. También podemos apreciar cada llamada que ha tenido nuestro servidor de SQL, ya sea un SP o una consulta T-SQL, además de los parámetros enviados.

A diferencia de la pantalla de arriba, acá podemos ver una paginación optimizada, y también podemos comparar las duración de cada consulta. También podemos copiar el código generado, ejecutarlo y verificar el porque del problema.
Otro punto a tener en cuenta es, si bien en un ambiente de desarrollo podemos usar Visual Studio 2005 para depurar, que pasa en un ambiente de pruebas, donde sólo tenemos SQL y IIS?, y sobre todo más cuando sabes que en el server de prueba, es cuando recién aparecen los problemas :D.
Además de las ventajas que le puede dar al desarrollador, hay otras fumadas que se pueden hacer con SQL Profiler:
P.D.: Traten de que la depuración con Visual Studio sea la última opción, sobre todo para soluciones con proyectos grandes, para mi es una tarea fastidiosa, aunque a veces necesaria, pero se puede evitar con herramientas como esta. Sólo es cuestión de acostumbrarse, verán que algún momento ante una pantalla no esperada, lo primero que harán será ir al profiler, en lugar depurar la aplicación :). Y bueno no te ahorras "el tiempo" que gastarías en depuración, pero esto sumado a otras cosas más, como adquirir mejores máquinas, aumentar la concentración, puede sumar y disminuir unos días de ineficiencia, sobre todo en un mes crítico como este, bueno para mi :D. Por cierto, debido a estro parece que sólo estare posteando los fines de semana :), hay mucha información que compartir y algunos anéctodas, del trabajo que contar, pero trato de tener los títulos anotados, así que algún día los contare :).
Saludos, desde Lima, con mucho frío por cierto.
Post cruzado
3Dev Blogs