Cuál es la mejor forma de trabajar con VFP y SQL Server.

[aaguilar]

Hola  todos.

Estoy empezando a desarrollar una aplicación en vfp y sql server. Quiero que me den sus comentarios acerca de cuál es la mejor manera de trabajar en este entorno; es decir, es necesario hacer SP en SQL donde se tengan consultas simples de dos campos? o crear las sentencias desde VFP y ejecutarlas con SQLEXEC(). Cuál sería la recomendación? trabajar todo desde SQL (Querys, cursores,funciones,etc) o trabajar de Modo Mixto (Hacer unas cosas en SQL y otras en VFP).

 

Comento esto porque en algún momento tendré que hacer Stored Procedures en donde tenga que manejar Insert, Update, delete en varias tablas y para eso, también tendría que hacer cursores en SQL para almacenar la información temporal. Por ejemplo: Si tengo que guardar información de una venta en donde intervienen las tablas "venta","detalleventa","Productos". A la hora de guardar podría hacer un SP en donde Inserte una venta, Inserte productos que contiene la venta (datos temporales mientras no elijan guardar) y actualizar la existencia de los productos involucrados; todo esto dentro de una transacción para asegurar los movimientos. Para hacer esto, tendía que manejar toda la información desde SQL, incluyendo cursores para datos temporales. Y llamarlos desde VFP.

 

En cambio, si trabajo de modo mixto, tendría que hacer los cursores desde VFP e ir armando el comando con las inserciones, actualizaciones correspondientes para cada tabla y además meterlo dentro de una transacción. Después ejecutarlo sqlExec().

 

Qué me recomiendan, cual es la forma más adecuada para trabajar. Cuales son las buenas prácticas para este tipo de desarrollo.

 

Por la atención, gracias.

Adrián Aguilar.

 

 

comenten.

[Alfonso Ramirez Diaz]

Estimado Adrian.

Yo pienso que una mejor forma no existe ya que cada programador tiene sus apreciaciones, por ejemplo llevo años trabajando con Foxpro y SQL Server y todo me ha funcionado espectacular, la forma que tengo de trabajar es la siguiente

1.- Me conecto siempre por ODBC

2.- No uso procedimientos almacenados por un tema de compatibilidad con distintos motores SQL.

3.- Toda la estructura de la database(s) la creo directamente desde Foxpro.

4.- Trabajo solamente con la instruccion SQLEXEC() y cursores temporales o tablas locales para mostrar la información en el cliente.

5.- Toda la lógica del negocio la hago en Foxpro porque como comentaba en el punto 2 no uso procedimientos almacenados.

--
_______________________________________________________________
Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
FoxPro" de Grupos de Google.
 
Para anular la suscripción a este grupo, envía un mensaje a:
mundovisualfox...@googlegroups.com
---
Has recibido este mensaje porque estás suscrito al grupo "Mundo Visual FoxPro" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a mundovisualfox...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--

Alfonso Ramirez Diaz

Gestpyme - Informática y Gestión

Fono: 055-833233

Móvil: 09-82239821

[Carlos Miguel FARIAS]

Depende de varios factores, personales y de la apliación a desarrollar.

Personales: Si tienes un buen "paquete" de rutinas y soluciones en VFP, pasar a usar a SP de SQL, puede llevarte a refactorizar bastante de lo que estás haciendo.

Si a largo plazo, tu idea es "abandonar" vfp por otro entorno front end, mantenerte con herramientas Microsoft, y no es mala idea usar SP, y hasta podría tener sus ventajas.

Si a plazo medio, tu idea es permitir que tu herramienta VFP pueda usar diferentes SGBD, todo lo que metas en SP después debes reconvertirlo a cada SGBD.

Si piensas migrar a la Web, SQL Server puede tener menor disponibilidad de hostings.

Todo lo anterior lo dejo en personal, porque son decisiones que afectarán en que deberás capacitarte o que alternativas futuras tendrás para otras herramientas.

En cuanto a la aplicación: La aplicación respondera una OLA: Objetivos, Limites y Alcances. Los objetivos son los requerimientos de alguien o alguien que podrá adaptarse a lo que tu desarrolles, o sea lo que describas en alcances. Y los limites, que muchas veces no se tienen en cuenta pero son la "muerte" de los sistemas, tienes que analizar el tema costos de usar SQL Server (la versión express alcanza?, el cliente ya usa otro SGBD?). Cuanto tiempo el Express aguatará antes de migrar a una versión de pago. Entorno solo escritorio, intranet, extranet.

Y como mix de ambos factores, el límite del tiempo en que debes tenerlo listo y cuanto sabes de VFP o de SP, para resolver las cosas en el tiempo apropiado.

Más alla de ello. Y porque sirve para practicamente cualquier SGBD, ya que confeccionar vistas en el servidor, que respondan a todos los requerimientos de datos de la aplicación. Eso implica lista de campos especificos, calculados, joins, orden, condiciones, agrupamiento, todo.
O sea en tus SQLExec, los SELECTs serán siempre:

SELECT * FROM VistaApropiada, de esa manera el servidor ya puede tener "compiladas" las vistas (parsing más plan de procesamiento) lo que hace que el servidor responda "optimo" y la transferencia de datos sea minimalizada.

Además, las vistas pueden dejar en cache los resultados y no sería extraño que otro cliente del sistema, reaproveche los datos, sin relectura.

Personalmente entre código en el lenguaje de Front End y SP, prefiero un mix.

Si los requerimientos de datos implican calculos que reducen el volumen de datos a transferir, de cabeza un SP que haga el proceso.

Si los calculos generan resultados que solo son necesarios para un cliente (por ejemplo, total de factura actual), uso el cliente para trabajar, o sea quito una elaboración de calculos en el servidor que solo aprovecha un cliente.

En fin. Lee, NO IMPRIMAS, y aprovechalo.

Saludos: Miguel, La Pampa (RA)

P.D. Si mi consejo lo quieres usar para higienizar la terminación de tu aparato digestivo, si sería conveniente imprimir, va a doler menos el cargo de conciencia de un arbol menos a limpiar el monitor (y ya es casi viernes)

 

[Miguel Antúnez]

Como dice Alfonso, no hay la mejor forma, hay la forma que uno considera mejor.

Aquí te van mis puntos de vista y la forma que trabajo. 

Trabajo a 5 capas

Capa 1 : Interfaz - VFP basado todo en clases visuales.

Capa 2 : Negocio - VFP basado en clases no visuales. 

Capa 3 : Conexion - VFP basado en clases no visuales. 

Capa 4 : Stored Procedures - SQL absolutamente toda interacción con las base de datos esta a través de SP

Capa 5 : Data - SQL Completamente relacionado usando triggers,funciones, vistas, defaults, constraints, etc. 

Justificaciones por la que trabajo baja esta forma: 

En primer lugar Seguridad, de ahí siguen performance, estabilidad, estandarización, escalabilidad, reutilización y por ahi algunas bondades mas que se me pasan.

Otra es sacar el máximo provecho de cada herramienta.

Saludos.

Miguel Angel Antúnez Camones
mant...@gmail.com