PortalSQL.

Com
Bienvenido a tu sitio web sobre tecnologías Microsoft de desarrollo
en general y sobre Sql-Server, Visual Basic y V.Studio .NET en
particular.
Mantienen este site Emilio Boucau y Miguel Egea.
Contigo desde Agosto de 2001

Si lo que quieres es comprar SQL-Server ...

PRINCIPAL CONTACTAR SUGERENCIAS FOROS

Visual FoxPro y Sql-Server

Martes 3 de Junio de 2003

INTRODUCCION

 Eldiseño y programación de una aplicación Cliente/Servidor involucra muchos aspectos importantes los
cuales llevaran a un feliz o fatal desenlace al momento de la implementación de la misma. Visual Fox Pro,
uno de los pocos leguajes de programación potentes, flexibles y de rápida comprensión, trae un motor de
base de datos propio, el cual es bastante potente pero que de igual forma no podría compararse al
rendimiento y desempeño de un servidor de bases de datos como lo es SQL Server.

Siempre he pensado y sostenido que el desarrollo de una pequeña o gran aplicación, no debe dejarse en
manos de un solo lenguaje de programación o un motor de bases de datos, sino que debe buscarse el
conjunto de herramientas que nos ofrezcan lo mejor de cada cual y aprovechar al máximo las posibilidades
que cada una nos ofrece. Por esa razón, voy a detallar a continuación, algunas técnicas de uso de VFP sobre
SQL para que podamos obtener el máximo de cada uno de los productos. Primero, vamos a separar a VFP
de su motor de base de datos local y vamos a hablar de Base de Datos cada vez que queramos hacer
referencia a SQL Server, dejando en claro que a VFP únicamente lo utilizaremos en su mayoría como el
producto que nos permitirá manipular los datos de nuestras bases de datos.

I.- CAMBIANDO LA IDEA

La normalización, la integridad, los índices, los procedimientos almacenados, las tablas, las vistas,
etc., son objetos comunes dentro de cualquier motor de base de datos. También son objetos que
existen dentro de un contenedor de datos como la DBC nativa de VFP, sin embargo, existen diferencias
bastante grandes entre la DBC de VFP y una base de datos de SQL Server. Por esta razón, no es igual
pensar y diseñar un modelo que funciona en VFP a un modelo que funcionará en SQL Server y, aunque
hiciéramos lo mismo para ambos, debemos tener presente que quizás funcione y si lo hace, el
desempeño que podamos obtener será totalmente diferente. ¿Porque puede fallar un sistema diseñado
y pensado en una DBC a un sistema diseñado y pensado sobre SQL? A continuación, detallaré las
diferencias de los objetos entre los diferentes entornos.

 
ESQUEMAS:

DBC DE VFP

Al crear una base de datos, Microsoft® Visual FoxPro crea y abre de forma exclusiva un archivo .dbc (Contenedor de
base de datos). El archivo .dbc almacena toda la información sobre la base de datos, incluidos los nombres de los
archivos y los objetos asociados a ella. El archivo .dbc no contiene físicamente ningún objeto de nivel superior, como
tablas o campos. En su lugar, Visual FoxPro almacena en el archivo .dbc punteros de rutas de archivo que apuntan a
las tablas.

SQL SERVER

Microsoft® SQL Server 2000 asigna una base de datos a un conjunto de archivos del sistema operativo. Los datos y
la información del registro nunca se mezclan en el mismo archivo, y cada archivo sólo es utilizado por una base de
datos. Las bases de datos de SQL Server 2000 tienen tres tipos de archivos:

         Archivos de datos principales

El archivo de datos principal es el punto de partida de la base de datos y apunta a los otros
archivos de la base de datos. Cada base de datos tiene un archivo de datos principal. La
extensión de nombre de archivo recomendada para los archivos de datos principales es .MDF.

         Archivos de datos secundarios

Los archivos de datos secundarios son todos los archivos de datos menos el archivo de datos principal.
Puede que algunas bases de datos no tengan archivos de datos secundarios, mientras que otras
pueden tener varios archivos de datos secundarios. La extensión de nombre de archivo recomendada
para los archivos de datos secundarios es .NDF.

         Archivos de registro

El archivo de registro almacena los cambios que se van haciendo a la BBDD y el estado final de los mismos
(confirmado o no confirmado). Luego, éstos son aplicados en la BBDD cuando se hace un checkpoint.

Como mínimo, tiene que haber un archivo de registro por cada base de datos, aunque puede haber varios.
La extensión de nombre de archivo recomendada para los archivos de registro es .LDF.

A diferencia de VFP, SQL Server si guarda dentro de sus archivos los objetos de la base de datos, y estos
objetos están definidos en:

Restricciones, Tablas, Desencadenadores, Valores predeterminados, Indices, Claves,

Procedimientos Almacenados, Tipos de datos definidos por el usuario, Funciones definidas por
el usuario y Vistas.

DIFERENCIA ENTRE LOS OBJETOS DE LAS BASES DE DATOS:

Aunque la comparación pareciera no tener sentido, estos datos están para la toma de referencia en
cuanto a la capacidad de los objetos que cada uno puede contener. Podemos evaluar únicamente el
objeto Tabla, y posteriormente veremos el por qué.

Nota: SQL Server puede tener hasta dos mil millones de tablas por cada base de datos.
ALGUNAS DIFERENCIAS NOTABLES ENTRE DBC Y BASE DE DATOS

  VISUAL FOX PRO SQL SERVER

Cantidad máxima de  1000 millones Limitado únicamente por

registros por tabla el espacio de
almacenamiento

Tamaño máximo de 2 gygabites Limitado únicamente al

una tabla espacio de
almacenamiento.

Máximo de campos 252 1024

por registro

Como pudimos observar rápidamente, no podemos ni realizar comparaciones en cuanto a capacidad,

pero esto nos da una pequeña pauta del porque debemos cambiar de idea. También debemos tomar
en cuenta y lo veremos mas adelante, el porque la frase de Divide y vencerás, es tan acertada cuando
diseñamos una base de datos de SQL Server, ya que no debemos tomar como parámetros de
rendimiento las capacidades de cada sistema. por tal razón no explicaremos como funciona el
contenedor de datos de VFP y nos saltaremos directamente a comprender como funciona SQL Server,
para que tengamos una clara idea de cuan grande es la diferencia entre los dos y podamos así,
CAMBIAR DE IDEA.

COMO FUNCIONA SQL SERVER:

Los datos de Microsoft® SQL Server™ 2000 se almacenan en bases de datos. Los datos de una base
de datos están organizados en los componentes lógicos visibles para los usuarios. Además, una base
de datos está implementada físicamente como dos o más archivos de disco.

Al utilizar una base de datos, se trabaja principalmente con los componentes lógicos, como tablas,
vistas, procedimientos y usuarios. La implementación física de los archivos es casi enteramente
transparente.
Cada instancia de SQL Server tiene cuatro bases de datos del sistema (master, model, tempdb y
msdb) y tiene una o varias bases de datos de usuario. Algunas organizaciones sólo tienen una base de
datos de usuario que contiene todos los datos de la organización. Otras organizaciones tienen bases de
datos diferentes para cada grupo de la organización y, en algunas ocasiones, una base de datos sólo
es utilizada por una única aplicación. Por ejemplo, una organización podría tener una base de datos
para ventas, una para nóminas, una para una aplicación de administración de documentos, etc.
Algunas veces, una aplicación utiliza sólo una base de datos; otras aplicaciones pueden tener acceso a
varias bases de datos. Hasta acá, podemos decir que estamos hablando de temas bastante parecidos
en el ambiente VFP, sin embargo debemos comprender que la estructura física de los archivos es
bastante diferente, para poder comprender como almacena SQL Server los datos en las tablas y
establecer un mejor diseño, debemos basarnos en lo siguiente, Los objetos de una base de datos de
Microsoft® SQL Server™ 2000 se almacenan como una colección de páginas de 8 KB. De allí, el alto
rendimiento y velocidad de acceso, porque todos los objetos están contenidos en un solo archivo de
datos, y cada página de datos dispone de una cabecera de 96 bytes que contiene información del
sistema como el identificador (Id.) de la tabla que es propietaria de la página. La cabecera de página
también incluye punteros a las páginas anteriores y siguientes que se utilizan si las páginas se vinculan
a una lista. Al final de la página se encuentra una tabla de desplazamiento de filas. Las filas de datos
ocupan el resto de la página. Las tablas de SQL Server 2000 utilizan uno de estos dos métodos para
organizar sus páginas de datos:

        Las tablas agrupadas son tablas que tienen un índice agrupado.

Las filas de datos están almacenadas en un orden basado en la clave del índice agrupado. El
índice se implementa como una estructura de árbol B que admite la rápida recuperación de las
filas a partir de los valores de claves del índice agrupado. Las páginas de cada nivel del índice,
incluidas las páginas de datos del nivel de hoja, se vinculan en una lista con vínculos dobles,
pero la navegación de uno a otro nivel se produce mediante valores de clave.

        Los montones son tablas que no tienen un índice agrupado.

Las filas de datos no están almacenadas en ningún orden particular ni tampoco hay un orden
particular en la secuencia de las páginas de datos. Las páginas de datos no están vinculadas en
una lista vinculada.

Las vistas indizadas tienen la misma estructura de almacenamiento que las tablas agrupadas.

SQL Server admite también hasta 249 índices no agrupados en cada vista de tabla o índice. Los índices
no agrupados tienen una estructura de árbol B similar a la de los índices agrupados. La diferencia está
en que los índices no agrupados no tienen ningún efecto en el orden de las filas de datos. Las tablas
agrupadas y las vistas indizadas mantienen sus filas de datos en orden de acuerdo con la clave del
índice agrupado. La colección de páginas de datos de un montón no se ve afectada cuando se definen
índices no agrupados en la tabla. Las páginas de datos permanecen en un montón a menos que se
defina un índice agrupado.

TIPOS DE DATOS

Tanto VFP como SQL Server tienen tipos de datos para almacenar información, dependiendo su
naturaleza continuación detallo los tipos de datos de SQL Server, muy similares a los de VFP. Aunque
alguna conversión a la hora de mapear un tipo de datos especifico de SQL a VFP puede suceder y
presentar o almacenar información errónea, es necesario tomar en cuenta como se manipulan y hacer
las pruebas respectivas. La información de detallada de cada tipo de datos puede verse en los BOL
(books on line de SQL Server)

INTEGERS, INT, SMALLINT, TINYINT, BIT, DECIMAL, NUMERIC, MONEY, SMALLMONEY, FLOAT, REAL,
DATETIME, SMALLDATETIME, CHAR, VARCHAR, TEXT, NCHAR, NVARCHAR, NTEXT, BINARY,
VARBINARY, IMAGE, CURSOR, SQL VARIANT, TABLE, TIMESTAMP, UNIQUEIDENTIFIER
 

Con esta explicación express de SQL Server, podemos empezar a tomar una idea diferente del manejo
y almacenamiento de datos en SQL Server, y quizá nunca tomamos la molestia porque ahora no es
problema el almacenamiento de datos, lo que significa la paginación de información en SQL Server, y
no quiero que confundamos el termino de pagina de datos con lo que significa espacio de
almacenamiento, siempre que podamos con un conjunto de registros, llenar, completar o dividir las
paginas de datos en SQL Server, lograremos obtener un mejor rendimiento y desempeño.

 EL DISEÑO

Es muy importante el diseño de una base de datos, es necesario tomar en cuenta elementos importantes en todo
diseño y orientarnos a lo que serán los datos de salida finales que tendremos, y quizá centrándonos mas en la salida
de información que en el ingreso, a que se refiere esto, a que en cada diseño nos tomemos la molestia de ver
independientemente de que mantengamos una integridad de información que nos sirva para validar el ingreso de
datos, como a obtener un buen esquema de almacenamiento y proceso, para poder producir salidas de datos de
forma mas rápida y eficaz. Los temas de normalización de datos, fundamentales para cada gestor de datos relacional
funciona perfectamente para mantener una integridad de datos, pero no siempre se adapta a dar una mejor
respuesta a la hora de consultar datos o generar informes. Podemos entonces valernos de algunos trucos en cuanto
a ganar velocidad perdiendo un poco de normalización, y al final el fin justificara los medios.

 Empezaremos a la carga en este sentido para que no se duerman, y veremos como trabajar con diseños sencillos
que nos darán una mejor respuesta que lo que normalmente podríamos realizar en Visual Fox Pro.

Vamos a ver dos diseños, el primero en VFP y el segundo en SQL Server, vamos a analizar el porque
del cambio entre uno y otro sistema y vamos a tomar en cuenta algunas de las ventajas que cada cual
tiene.
como podemos ver en los diagramas, el diagrama de SQL Server tiene mas tablas que VFP, porque?, la
respuesta es sencilla, la implementación de triggers de tipo after o instead en SQL Server, nos permiten
implementar procesos específicos  después de cierta acción (insert, delete, update) y poder implementar
tablas adicionales para totales como lo vemos en el diagrama, podemos tener la tabla de transacciones que
será la operativa y la cual tiene el campo fecha, pero podemos tener dos tablas adicionales donde guardamos
suma de datos de venta por mes y año y otra con el total de ventas por año, las cuales podremos enviar a
actualizar en los triggers de nuestras tablas de SQL Server según sea el caso (insert, update, delete). y
cuando necesitemos tener, registros de los totales de ventas por periodos, basta con crear una instrucción
que genere esa información. Ustedes también podrían decir que eso se puede implementar en VFP, y claro
que se podría, pero todos sabemos lo complicado y difícil que es mantener integridad de datos
programaticamente ya que los mismos no son controlados por eventos de la base de datos sino por propios
eventos en nuestra aplicación. Si bien es cierto también podríamos implementar eventos de insert, delete o
update en VFP, pero créanme que será mas el dolor de cabeza, tanto que al final casi optarían por aplicar
procesos que lo hagan desde la aplicación. o en su defecto, diríamos, creamos un índice por fechas o
hacemos un query para sumar, perfecto, pero vamos a hablar de que la tabla de transacciones tiene
30,000,000 de registro de ventas de los últimos tres años. la tabla de productos tiene 10,000 productos y
necesitamos llevar el control de ventas por mes por cada producto y un acumulado por año por cada
producto, diarias, bueno, si lo planteas así, mejor dividimos los datos, pero y garantizamos que cada
inserción, eliminación y modificación tendrá las tablas correctamente actualizadas??, seguro que no.
Entonces preferiríamos tenerlo todo en una sola tabla con un índice por fecha, pues para que sea más rápido.
y son problemas que al iniciar un diseño, no tomamos en cuenta y que ya cuando el sistema se agiganta,
entonces empezamos a implementar y modificar nuestros programas, aunque no lo hiciéramos de esa forma,
en SQL podemos implementar luego esos triggers sin cambiar una sola línea de código en nuestros
programas. Quizá parezca gracioso y me digan que de igual forma existen triggers en VFP, pero bastara con
que tengamos que implementar triggers para múltiples accesos de datos a la vez, o triggers recursivos, o
implementación de UDF's dentro de triggers y verán porque cambiar de concepto.

Otra parte importante de este diseño como pudieron notar, que SQL puede manejar índices naturales compuestos y
no tendremos necesidad de crear índices por datos agrupados como tuvimos que verlos en nuestro diagrama, o un
campo donde almacenar la suma de nuestra llave primaria para luego colocarlo como PK, además si pensamos en
rendimiento, recordemos que VFP copia en un archivo por separado los valores de los índices con lo cual nuestra
tabla se volvería bastante grande. No estoy con esto diciendo que no se pueda implementar este tipo de diseño en
VFP, sino que únicamente nos será mas fácil la manipulación de datos y el control de errores en SQL con este tipo
de estructura.

También me gustaría dejar claro que casi cualquier situación que pueda realizarse en SQL Server, puede hacerse en
VFP, el punto es, la facilidad, conveniencia y seguridad que los modelos puedan aportar en cada entorno y el cambio
de idea de acceso y almacenamiento de datos, será lo que haga la diferencia entre rendimiento e integridad de
nuestra información.

DIFERENCIAS ENTRE ACCESO A DATOS EN ENTORNO VFP Y EL ACCESO A DATOS DE

SQL SERVER

Un punto de suma importancia que hay que tener en cuenta, es la forma en como procesamos los registros en el
ambiente nativo de VFP y el ambiente de SQL Server, VFP por ser un lenguaje orientado al manejo de datos, tiene
muchos comandos añadidos que trabajan directamente sobre los registros de las tablas, digamos una sentencia
SCAN, es un comando que únicamente trabajara sobre un conjunto de registros (tablas, vistas locales, vistas
remotas), un comando FOR podría realizar lo mismo, pero no necesaria mente sobre un conjunto de datos. El
proceso de manipulación de datos en VFP, es registro por registro, y aunque utilizáramos una sentencia SQL  de
VFP, siempre se estaría valiendo de la optimización que cree necesaria para procesar registro por registro, tomando
en cuenta que estas no son tan potentes como en SQL Server. Por otro lado, SQL Server, se basa en el proceso de
datos en lotes, lo que nos permite realizar una instrucción para un conjunto dado de registros. Veamos este ejemplo
sencillo.

El gerente de la empresa, nos dice que necesita que creemos una opción, que reactualice las fechas de
ultima venta de cada producto que empiece con las letras A,B,C. (Suponiendo que esto ya lo hace
normalmente la aplicación, sinembargo es únicamente para asegurarnos que las fechas están
correctas.)

 
VFP

Haciéndola de la forma un poco mas compleja y utilizando sentencias SQL, podríamos hacer lo
siguiente:

Primero creamos una función, a la cual le pasaremos como parámetro el código del producto.

function calcula_fecha

lparameter pid_producto

select max(fecha) as fecha from tbl_transacciones where id_tipo_transaccion +'_'+id_transaccion in (select id_tipo_transaccion
+'_'+id_transaccion  from tbl_detalles where id_producto = pid_producto) into cursor ultima_fecha

Cultima=ultima_fecha.fecha 

Update tbl_productos set ultima_venta= iif(isnull(Cultima),ultima_venta,Cultima)

where id_producto=pid_producto

 sele ultima_fecha

use

endfunc

**Fin de la Función

NOTA: este proceso puede realizarse de otra manera, pero buscamos siempre una forma mas compleja tomando en cuenta el rendimiento.

Ahora paso siguiente, tendríamos que hacer esta sentencia para ejecutar la función, calcula_fecha

select calcula_fecha(id_producto) from tbl_productos where substr(id_producto,1,1)  in ('A','B','C') order by

id_producto into cursor Producto

** Fin del proceso de Actualización

Perfecto, ya tenemos una función en VFP que realiza esta tarea y es bastante rápida teniendo en cuenta que ya
tenemos 130,000 productos en la tabla productos y 30,000,000 de registros en la tabla de detalle de ventas.
OK, a que viene esto, se preguntaran, de igual forma se podría hacer en SQL Server, este no es el punto,
imaginemos ahora que el punto es el siguiente: Necesitamos mover esta base de datos de VFP a SQL Server, quizá
cambiar el código o hacer este código sobre vistas remotas??, ese es el punto. Corremos nuestro programa de SQL
Upsize y ya tenemos nuestra base de datos con las tablas y los registros en SQL Server. Olvidémonos que
tendremos  si usamos o no triggers en VFP, volver a escribirlos a SQL Server, ya que no funcionaran, por lo tanto,
eso lo dejamos a un lado. Ok, la pregunta del millón, Como hago que este procedimiento funcione en SQL Server??.
La primera impresión seria, Ok, hagámoslo sobre las vistas remotas que nos creo el asistente, o creamos una vista
remota que solo nos devuelva el max de las fecha y corremos sobre ello nuestro procedimiento sin ningún cambio,
hagámoslo, y veamos el rendimiento.

Pasos:

a) Creamos una vista remota que nos devuelva únicamente el max de la fecha del cada producto.

b) Creamos una vista remota actualizable para nuestra tabla de productos y supongamos que la vista remota tiene el
mismo nombre que nuestra tabla original, para no modificar los procedimientos.

Ejecutamos nuevamente nuestra sentencia para correr el proceso.

select calcula_fecha(id_producto) from tbl_productos where substr(id_producto,1,1)  in ('A','B','C')

order by id_producto into cursor Producto

luego grabamos los datos en SQL Server

=tableupdate(.t.,.t.)

Perfecto, actualización concluida, pero que paso???, Porque tardo más esta ejecución que cuando la teníamos en
VFP, que pasa, será acaso mas lento SQL Server que VFP??. No, y allí esta el punto de porque cambiar de idea, en
primer lugar, porque cargarle al front end toda la tarea de el proceso de datos, en lugar del servidor, donde se
ejecutara mas rápido y nuestra aplicación estaría disponible para poder realizar otras tareas. Entonces decimos, OK,
vamos a pasar ese código de VFP a SQL Server, lo primero que se nos ocurre es, Ok, creamos un stored procedure
en SQL Server y lo ejecutamos con VFP, lo hacemos y quizá no tomamos en cuenta lo siguiente, el aspecto de
rendimiento, hacer esto podrá aumentar la velocidad de nuestra aplicación, pero entra en juego otro punto, y el
servidor??, quizá no nos preocupamos por la carga del servidor, da igual es un servidor de bases de datos no, pues
que haga su trabajo!!. Créanme, el tema de rendimiento en SQL Server es un extenso tema que se trata en varios
libros, hay incluso algunos libros gigantescos que tratan únicamente de eso, tuning, es necesario determinar la mejor
forma de realizar el proceso,  vamos a probar primero dos sentencias, una será, tratar de traducir con nuestra idea de
proceso de registros el código completo desde VFP a SQL Server así:

Primero creamos nuestro Procedimiento:

Nota: las variables en SQL Server se declaran con @ antes del nombre y será necesario expresar el tipo de datos
que manejaran, de igual forma únicamente estarán disponibles para la sesión de datos que la creo y dentro del
procedimiento que se creo.

create procedure .dbo.proc_calcula_fecha @id_producto

as

begin

declare @cultima datetime

select @cultima=max(fecha) as fecha from tbl_transacciones where id_tipo_transaccion +'_'+id_transaccion in (select id_tipo_transaccion
+'_'+id_transaccion  from tbl_detalles where id_producto = @id_producto)

Update tbl_productos set ultima_venta= isnull(@Cultima,ultima_venta)

where id_producto=@id_producto

return

end

Perfecto!!!, Ya tenemos nuestro procedimiento en SQL Server con muy pocos cambios en relación al código de VFP
original, Esto es cosa sencilla se piensa.. Vaya, quien diría que SQL Server es tan fácil y sencillo, así que ahora
ejecutamos nuestro procedimiento desde VFP.

** Creamos toda nuestra cadena de conexión sqlconnect, sqlprepare y luego enviamos

a ejecutar el código de esta forma:

select id_producto from tbl_productos where substr(id_producto,1,1)  in ('A','B','C') order by id_producto into cursor Producto

select productos

go top

scan

=sqlexec('Cadena conexion','exec proc_calcula_fecha ?producto.id_producto')

endscan

sele productos

use

Perfecto!!, Ganamos mas rendimiento, y aun así te preguntas, será esto lo optimo??, Quién determina lo optimo??,
no existe una regla que te diga que ASI debe hacerse, la mayoría de los problemas y necesidades son nuestros,
sinembargo, siempre existe mas de una forma de hacer algo, por allí se dice que por lo menos existen tres formas de
hacer las cosas si no, no existe ninguna, y el determinar que o cual forma es la mejor, es un conjunto que se crea,
partiendo del diseño, estructuración, normalización, desnormalizacion, según sea nuestra necesidad a lo que habría
que sumarle la estructura de red y la velocidad y memoria de nuestros servidores. No nos vamos a adentrar mas en
el tema de rendimiento, porque eso es otra historia, pero si vamos a tomar en cuenta algunos procesos sencillos para
determinar estos factores.

DETERMINANDO ALGUNOS FACTORES QUE AYUDAN EN EL PROCESO DE DATOS DE

LADO DEL SERVIDOR

Nuestros procesos ya están del lado del servidor, y funcionan, pero cuando podremos determinar que es lo optimo?.
Como decía antes siempre hay una mejor forma de hacer las cosas, o quizá una peor, esto lo debemos tener muy
en  cuenta a la hora de desarrollar una aplicación en VFP si pensamos usar SQL Server. Siempre evaluemos las
mejores opciones, siempre pensemos a futuro, lo mas que podamos, tratemos de aprender técnicas en SQL Server,
y leamos algunos libros, tratemos de hacer lo mas que podamos del lado del servidor y si lo hacemos de esta forma,
siempre busquemos una manera eficaz, recordemos que SQL Server trabaja con conjuntos de registros y
olvidémonos ya de pensar en el proceso de registro por registro. Entonces que hay de malo en lo que hicimos??, Si
funciona.!! , Claro que funciona, pero si podemos notar, seguimos enviando registro por registro a nuestro servidor
para que ejecute media tarea del lado del servidor y media tarea del lado del cliente. Ok, pensamos, entonces como
podemos hacerlo??, A continuación pondré dos formas de hacerlo, hay mas, pero estas serán dos formas sencillas y
luego evaluamos el rendimiento.

Forma A

Usando Cursores.

create procedure .dbo.proc_calcula_fecha

as

begin

declare @id_producto char(10)

declare @cultima datetime

declare listado cursor for select id_producto from tbl_productos where substring(id_producto,1,1) in ('A','B','C') order by id_producto

open listado

fetch listado into @id_producto

while @@fetch_status=0

begin

select @cultima=max(fecha) as fecha from tbl_transacciones where id_tipo_transaccion +'_'+id_transaccion in (select id_tipo_transaccion
+'_'+id_transaccion  from tbl_detalles where id_producto = @id_producto)

Update tbl_productos set ultima_venta= isnull(@Cultima,ultima_venta)

where id_producto=@id_producto

fetch listado into @id_producto

end

close listado

deallocate listado

return

end 

Forma B

Usando query Simple

Creamos primero un vista en SQL que nos devuelva solo el max(fecha) y el código de producto de
cada producto, a esta le llamaremos vw_ultimas

create procedure .dbo.proc_calcula_fecha

as

begin

Update tbl_productos set ultima_venta=isnull(b.ultima_venta,a.ultima_venta)

from tbl_productos a, vw_ultimas b where a.id_producto=b.id_producto and

substring(a.id_producto,1,1) in ('A','B','C')

return

end

Bueno, hemos dado tres ejemplos de realizar el mismo proceso en SQL Server, ahora se preguntan, cual es el mejor,
definitivamente que ninguno, podemos mejorarlos utilizando joins, usando UDFS, creando mas índices, etc. Pero
como determinamos esto, básicamente de esta forma. SQL Server tiene una herramienta que se llama QUERY
ANALYZER, donde podemos ejecutar nuestros comandos de prueba, de igual forma el QUERY ANALYZER, tiene
opciones para mostrarnos un plan de ejecución de nuestras consultas, y hasta uno para hacer TUNING de los
índices, el cual después de evaluar nuestras sentencias nos recomendara la creación de índices para una ejecución
mas rápida de nuestros procesos. No entraremos en detalle sobre el uso de esta herramienta, pero el BOL (books on
line) que trae SQL Server puede explicar algunas tareas que podemos realizar con en QA. Desde este momento les
diré, que no es recomendable utilizar Cursores, o selects in porque demoran demasiado, y hacen demasiado lento el
proceso de datos, casi todo lo que se puede hacer con Cursores se puede hacer mucho más eficiente sin ellos, pero
no significa que no se usen, en determinado procesos, yo los he utilizado, pero trataremos lo menos posible de
hacerlo. No vamos a introducirnos mas dentro del tema de INDICES, porque ese es otro rollo gigantesco y este no
pretende ser un manual de SQL Server, únicamente una pequeña ayuda para mejorar los tiempos de respuesta de
nuestras aplicaciones basadas en MSSQL. Lo que si les diré, es que hay que tener bastante presente el uso de
índices cuando trabajemos con VFP y SQL, porque si bien los índices son buenos, la exageración en los índices
también puede causar lentitud de respuesta cuando las tablas tienen triggers que realiza procesos, pero de los
triggers, procesos e inserción de registros, hablaremos en otros capítulos mas adelante. Suerte y nos vemos en la
parte II.

Fernando España

[email protected]

MCSE

Jorge Mota

[email protected]

Representante regional de Guatemala Portalfox

Emilio Boucau

MSSQL MVP

www.portalsql.com

Nos importa mucho tu opinión, puntúa este artículo en sus dos vertientes, calidad técnica e interés. El primer parámetro nos servirá para
mejorar poner ejemplos más complejos o más sencillos y el segundo para escribir más de aquello que más os importe.

Desde el punto de vista técnico el articulo

es : Muy bueno Bueno Aceptable Regular Malo

El artículo me ha resultado Muy Interesante Interesante Aceptable No me interesaba mucho Ni

lo he leído
Introduce tus comentarios, nos importan mucho

Vuestros comentarios
.-Aunque aun no he trabajdo con SQL el momento para ello esta mas cerca de lo que pienso, y con este articulo han contribuido a
aclararme algunas dudas, tan es ase que con su permiso lo voy a bajar para tenerlo siempre en cuenta Miguel Morales
.-quisiera saber mas acerca del producto de sql que tiene por ejemplo que es model tempdb msdb
.-Normalmente para que alguien conteste lo mejor es preguntar en los foros, model, tempdb y msdb son bases de datos del Sqlserver,
son internas y para el uso del producto.
.-al articulo solo le falto como hacemos que se conecte visual fox pro con sql server, para los que no tenemos experiencia nos quedamos
igual
.-muy buen articulo
.-PODRÍAN PONER MAS EJEMPLOS DE CÓDIGO VISUAL FOX VS. SQL SERVER? GRACIAS. ROGELIO ANDRÉS. PUEBLA, MÉXICO.
.-PODRÍAN PONER MAS EJEMPLOS DE CÓDIGO VISUAL FOX y SQL SERVER
.-Me parece muy completa la informacion que se ha dado en relacion al tema. Mucha gente piensa que el trabajar con VFP, es tener la
potencia maxima.ERROR BRUNO DIAZ
.-Es un articulo interesante, si sería bueno que recomendaran algún libro sobre este tema, de esta forma podriamos consultarlo, de esta
forma podriamos despejar lagunas lagunas que quedan. Sobre todo con el código de SQL.
.-Muy interesante el tema, aunque poco documentado, seria bueno tener mayor documentación especialmente para manejo y llamado de
los procedimientos almacenados del lado del SQL Server.
.-poner mas informacion sobre sql
.-Me gustaria ver un articulo que trate sobre como conectarse a sql, pero mas que eso hacer un ejemplo de un pequenio programa de
altas bajas y cambios, muy sencillo. Para conocer una forma de acceder a SQL que sea efectiva.... (sera mucho pedir)
.-Es muy buen articulo, personalmente desarrollo en visual foxpro y sql server se los recomiendo es una herramientaza
.-Sin duda es un buen articulo, pero no es posible que quieramos matar una mosca con un fusil. Definitivamente Foxpro es poderoso
pero hay que saber cuando usarlo(me refiero al tamaño y complejidad y recursos que se tengan), lo mismo que Sql Server
.-Muy interesante
.-justamente lo que estaba buscando para esclrecer algunas dudas ,Ariel rodriguez de Paraguay
.-necesito saber como puedo hacer append blank a una vista para luego enviarla a la base de daos SQL y administrar las transacciones
.-Felicitaciones Emilio, bueno tu artículo lo he leido mas de una vez. Desarrollo en Visual FoxPro y estoy en el proceso de querer
aprender a desarrollar aplicaciones Cliente/Servidor <>
.-soy programador en visual foxpro y deseo comenzar a crear aplicaciones cliente servidor, pero es dificil conseguir material en la red
(VFP + SQL), esta iniciativa me parece fabulosa, ojala continue. Gracias.
.-Me intereso la forma en que se puede dar el diseño de la BD en SQL ojala se hable mas al respceto, la idea de mantener la integridad
de la información y el acceso de datos por lotes que ofrece SQL. Muchas gracias por la información._MonjE_
.-La verdad esta muy bueno lo que documentastes aunque falto un ejemplo pratico entre esa conexion. Yo manejo este tipo de conexion
pero a esta documentación le hace falta www.foxjose.vze.com
.-podrian poner ejemplos de como insertar imagenes y archivos de sonido en SQL