Más velocidad para SQL Server 7

En realidad tengo dos trucos bajo la manga: uno que puede aplicarse a cualquier sistema de bases de datos al que accedamos mediante ADO, y otro específico para SQL Server.

TRUCO NUMERO UNO: "EXECUTE NO RECORDS"

Suponga que quiere ejecutar una o más sentencias SQL, y que no espera que estas sentencias devuelvan un conjunto de registros. Por ejemplo, usted quiere disparar un procedimiento almacenado que realiza una transferencia de fondos entre dos cuentas. O que quiere ejecutar una instrucción update directamente sobre los registros de cierta tabla que cumplen alguna condición. Y pongamos por caso que estamos trabajando con ADO.

Para lograrlo, tenemos varios medios a nuestro alcance: si se trata de una llamada a un procedimiento, podemos recurrir a TADOStoredProc. Pero también podemos indicar las instrucciones en la propiedad SQL de un TADOQuery y entonces ejecutar el método ExecSQL; o echar mano de TADOCommand, poner las sentencias en CommandText, dejar en CommandType el valor cmdText y llamar a Execute.

En todos estos casos, es sumamente conveniente (y aquí es donde está el "truco") retocar la propiedad ExecuteOptions, que es común a todos los componentes mencionados, y añadir la opción eoExecuteNoRecords. Esta opción fue añadida en la versión 2.0 de ADO (Delphi se basa en la 2.1) y evita un problema introducido en las versiones anteriores, en las que se generaba un conjunto de registros de respuesta vacío incluso para operaciones directas de actualización. Esta generación inútil se sigue manteniendo por compatibilidad... a no ser que incluyamos la opción antes explicada. Al evitar la respuesta innecesaria, estamos liberando principalmente a la red de la transmisión de paquetes sin sentido alguno.

TRUCO NUMERO DOS: "SET NOCOUNT ON"

Y hablando de información innecesaria, he podido comprobar en mi propia piel las consecuencias de dejar con su valor por omisión una opción de configuración de SQL Server aparentemente inofensiva. Había programado un procedimiento almacenado con el objetivo de realizar una complicada puesta a punto de cierta base de datos por las noches. Este alevoso procedimiento nocturno disparaba centenares de instrucciones de selección y modificación sobre una base de datos bastante grande.

Desde un ordenador cliente se realizaba la petición de ejecución, consistente como he dicho, en una simple llamada a procedimientos. ¿Podría usted imagenar, sin embargo, que SQL Server envía un mensaje de confirmación al cliente cada vez que ejecuta cada una de las instrucciones SQL anidadas dentro del procedimiento? Increíble, pero cierto. En realidad, estas notificaciones de "ejecución parcial" pueden ser útiles, sobre todo si la ejecución se produce de forma asíncrona (no era mi caso). Pero son un desperdicio de ancho de banda para la red. Y como sabemos, el recurso más limitado en sistemas grandes es precisamente la capacidad de transmisión de datos de la red.

La forma de evitar estas notificaciones es, sin embargo, muy sencilla. Basta con ejecutar una sentencia de configuración antes de lanzarse a ejecutar con procedimientos con las características mencionadas:

  set nocount on
  execute isGenerateGroups
  set nocount off

Puede parecer más sencillo ejecutar la primera instrucción al iniciar la conexión y mantenerla activa durante la duración de la misma. Pero, según la documentación que he podido consultar, al menos ODBC necesita estas notificaciones en algunos casos, y he optado por ser prudente. De todos modos, he logrado reducir el tiempo de ejecución del procedimiento ... ¡a tres cuartos del tiempo original!