Limitaciones de la depuración de SQL
Actualización: noviembre 2007
Este tema se aplica a:
Edición |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
|
|
Standard |
|
|
|
|
Pro y Team |
.gif) |
|
|
|
Leyenda de la tabla:
|
Se aplica |
|
No procede |
.gif) |
Comando o comandos ocultos de manera predeterminada. |
Hay varias limitaciones generales para la depuración de SQL que se describen en esta sección.
Depuración de SQL de varios niveles
Al depurar las aplicaciones de varios niveles, no se puede utilizar Paso a paso por instrucciones para avanzar desde el código en el nivel de aplicación (C#, Visual Basic o C++) hasta el código en SQL Server 2005 (T-SQL o SQL CLR). Por el contrario, se debe establecer un punto de interrupción en el código del procedimiento almacenado y presionar Continuar (F5) para ejecutar el código hasta el punto de interrupción. También puede utilizar Ejecutar hasta el cursor para llegar al punto deseado, sin utilizar un punto de interrupción. Observe que dentro del nivel SQL Server 2005, se puede avanzar desde el código T-SQL a SQL CLR y viceversa.
Tampoco puede avanzar en la otra dirección, o sea, del código de procedimiento almacenado al código en el nivel que llamó al procedimiento almacenado. Si desea seguir depurando después de volver al nivel de la aplicación, coloque un punto de interrupción en el código de aplicación después del punto desde el que se llama al procedimiento almacenado.
La agrupación de conexiones es una técnica para mejorar el rendimiento de la aplicación. Cuando una aplicación cierra su conexión de datos, una conexión de SQL Server no se cierra totalmente, sino que se mantiene en un grupo que se puede volver a utilizar si la aplicación intenta reabrir la conexión posteriormente. No obstante, cuando se restablece una conexión a través de un grupo de conexiones, no se vuelve a habilitar la depuración de SQL.
Debe deshabilitar temporalmente la agrupación de conexiones durante la depuración. Para ello, escriba "Pooling=false" en la cadena de conexión utilizada para conectar con SQL Server. Cuando concluya la depuración, quite este atributo de la cadena de conexión y se habilitará de manera predeterminada la agrupación de conexiones.
Una aplicación administrada puede conectarse a un origen de datos de SQL Server mediante el Proveedor de datos de .NET Framework para SQL Server, que proporciona mejor rendimiento que la conexión con OLE DB u ODBC. En una misma sesión del depurador, puede realizar depuración administrada y depuración de SQL.
Si una aplicación administrada está en ejecución y se establece una asociación mediante el depurador, tiene la posibilidad de elegir el tipo de depuración que desee realizar. Si desea realizar una depuración de SQL, debe elegir la depuración de SQL y si desea depurar código SQL CLR, además debe especificar la depuración administrada.
La depuración de SQL sólo se puede realizar una vez asociada a una aplicación en ejecución. No obstante, tenga en cuenta que solo se pueden depurar las conexiones a bases de datos creadas después de completar la Adjuntar. Por tanto, si una aplicación llama a un procedimiento almacenado que tarda mucho, no podrá asociarse a la conexión que llamó al procedimiento almacenado, sino solo a nuevas conexiones que llaman al procedimiento almacenado después de haberse conectado a la aplicación.
Si está depurando mediante una conexión establecida con OleDbDataAdapter y deja pasar demasiado tiempo después de llegar al punto de interrupción, se agotará el tiempo de espera de la conexión. Cuando intente continuar la depuración después de haber agotado el tiempo de espera (eligiendo Continuar en el menú Depurar, por ejemplo), el depurador dejará de ejecutarse (en lugar de continuar). Éste es el comportamiento normal. El depurador deja de ejecutarse porque OleDbDataAdapter, a diferencia de SqlDataAdapter, no produce una excepción cuando se agota el tiempo de espera. Para evitar este problema, establezca un valor de tiempo de espera alto cuando utilice OleDbDataAdapter.
Para obtener información sobre la configuración del valor del tiempo de espera para proveedores de datos de .NET Framework, vea OleDbCommand.CommandTimeout (Propiedad) y SqlCommand.CommandTimeout (Propiedad) en la documentación de la biblioteca de clases de .NET Framework.
Para obtener información de última hora sobre las tecnologías MDAC, vea el sitio Web Microsoft Universal Data Access https://www.microsoft.com/data.
Otras limitaciones
Para depurar los desencadenadores hay que activarlos: los desencadenadores no se pueden depurar directamente. Inicie la depuración en un procedimiento almacenado ya que esto activará al desencadenador.
Durante la depuración en tiempo de ejecución, una serie de selecciones secundarias (por ejemplo, en una unión) pueden llenar el búfer de red. Esto puede hacer que se detenga en código que normalmente funciona bien. Para obtener más datos, utilice RecordSet.MoveNext y RecordSet.NextRecordSet.
Si el nombre de un procedimiento almacenado contiene comillas, puede recibir un mensaje de error del depurador. Para obtener más información vea, Error al depurar procedimientos cuyos nombres contienen comillas.
Los valores almacenados en caché no se modifican automáticamente. No siempre se puede esperar que los cambios que se realicen en variables locales o parámetros almacenados en caché por el intérprete de SQL tengan efecto en el intervalo durante el cual se recorre una instrucción SQL. Aunque pueda haber modificado el valor, es posible que nunca se vuelva a comprobar. No se puede forzar la actualización de los valores almacenados en caché. La existencia de valores almacenados en caché se debe a que el plan de ejecución de SQL Server determina que los valores de algunas variables no se cargarán dinámicamente para cada instrucción que se ejecute o a la que se haga referencia. Para obtener más información, busque "SHOWPLAN" en la documentación de SQL Server 2005.
No es posible establecer una asociación a un proceso nativo de SQL Server a la vez que se depura un procedimiento almacenado.