Como se trabaja con VFP-Firebird u otros SGBD? Qué es lo mas recomendable..

[Fox Learner]

Mi pregunta ahora no está relacionada con "codigo" sobre como
conectarse a Firebird 2.5 usando strings. Digamos que eso ya lo
entendí...

Ahora necesito comprender que es lo que debo hacer para trabajar con
VFP9 Y Firebird 2.5

Qué es lo recomendable?:

Por ejemplo, si voy a hacer una consulta, un agregado, una
actualización, un borrado, cual es la forma mas recomendable de
realizarlo.

Veo que Walter creó una clase.

¿Para que sirven ese tipo de clases?...

¿Quiere decir que cuando uso una clase como esa ya no me preocupo por
verificar la conexion vez tras vez porque eso lo hace la clase?..

Intentaré explicarme mejor en cuanto a qué es lo que no comprendo en
el siguiente post..

Gracias!

[Sharp Usr]

Ahora entiendo porque resistes usar .NET, jejejeje.

Saludos paisano.

[Fox Learner]

Entiendo que puedo hacer por ejemplo una consulta desde Fox a Firebird
y mostrar los datos en un cursor, el cual a la vez puedo mostrarlo en
un grid direccionando el cursor al recordsource del grid.

¿Tengo que saber lo de "buffering" y "transacciones a nivel de buffer"
para manipular registros de esta forma?...

Cual es el proceso para trabajar con Firebird en una LAN?...

Es decir:

1. Si deseo añadir registros que se haría?...

a)Intentar Conectarse
b)Si la conexion esta activa hacer inserts o appends
c)desconectarse

Considerando que no se está usando un "hosting" y la conexion será la
equivalente a cuando trabajamos de forma nativa con fox y por lo tanto
bastante estable, tengo que estar conectandome y desconectandome cada
vez que necesito hacer una operación específica sobre el SGBD?...

O solo me conecto al SGBD cada vez que un usuario inicia sesión, luego
agrego, modifico, borro, etc registros y me desconecto cuando el
usuario cierra su sesion?...

¿Qué otras implicaciones debo tomar en cuenta?...

Pretendo que este hilo capte la mayoría de las inquietudes o
cuestionamientos que puedan surgir al trabajar con un SGBD, así que
pueden comentar con libertad siempre y cuando tenga relacion con los
SGBD.

Intento entender cuál es el proceso mas recomendable para trabajar con
los SGBD.

Gracias!

[Fox Learner]

Sharp, ya estoy viendo lo de crear el diseño de DB con el DBDesigner
para luego generar un script SQL y despues de crear una BD con el
phpmyadmin importar las estructuras al mismo.

Lo siguiente será usar un conector para Mysql que conecte desde C#,
pero eso será hasta la próxima semana.

Antes vimos el ERWin en la escuela para crear las entidades y sus
relaciones así como el enterprise architect para diagramas de sistemas
basados en reglas (IA, Redes Neuronales y Sistemas Expertos).

Durante la carrera usamos algunas cositas como el Mysql-Front, el
navicat lite, etc.

Bueno, para acabar pronto.. Digamos que vimos muchos "trozos" de
conocimiento disperso.

Mi problema es que adolezco de "conocimientos básicos" que son
esenciales para todo programador.

En eso andamos..

Quizás tu seas un experto y por eso te parezca "irrisorias" mis
preguntas..

El caso, es que yo vine a este foro a aprender de la gente que sabe.

Si puedes ayudarme, por favor ayuda. Si no puedes o no quieres.. no sé
que proposito tiene tu participación en foros como este??

Saludos!

[Sharp Usr]

Mi incripción en este "Grupo de Visual FOX PRO" fue aprender de "VISUAL FOX PRO" para decodificar un Sistema. 

Para SQL, C#, MySQL, ERWIN, Redes Neuronales, IA, Sistemas Expertos, SGDB hay un Mundo afuera...

¿Que código hay que crear, para ayudarte?

[Fox Learner]

Sharp,

No me entendiste.. El ultimo mensaje fue a modo de explicación para
ti, de lo que vi en la escuela para que veas que tengo "trozos de
conocimiento" de varias cosas, pero me faltan cosas básicas pero
esenciales.

La pregunta sigue en pie.. acerca de como trabajar con firebird desde
VFP.

Repito:

[Miguel Antúnez]

A mi parecer la manera correcta de trabajar con un  SGBD es a través de Procedimiento almacenados, cualquier tipo de transacción, inclusive los select, ya que dan mas opciones de seguridad y integridad de tu información.

teniendo esto como partida, lo que se hace en VFP es mas sencillo, llamar Stored procedures

en mi caso a  través de una clase de tipo conexión, donde se centraliza todos los llamados a los SP

la otra capa es la de negocios donde tengo la lógica de los objetos del sistema

y por ultima la capa interfaz también estructurada en clases.

también me conecto y desconecto en cada transacción, al principio me conectaba al inicio y me desconectaba al cerrar la aplicación, 

cambios notorios no he tenido ni ventaja ni desventaja, alguno que se puede rescatar es la perdida de red ya que el primero no para conectado y no tengo errores por perdida de red.

al tener la capa conexión puedes configurar cualquiera de las 2 formas.

Saludos.

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

[Sharp Usr]

Coincido con Miguel, trabajar en Capas resulta idónea solución con VFP, y sumamente sencillo emplear Stored Procedures.

[Carlos Miguel FARIAS]

Trabaja con SP es buena idea y mala idea.
Si tenes buen control sobre la bd (resultas ser el ABD, p.e.) puede ser una buena solución.
Si no tenes control sobre la bd, esl "cliente" o un intruso, puede acceder a tu conocimiento del negocio, es como tener parte del código fuente "expuesto", porque el que accede a la bd, vería el código del SP.
En sql server se que el sp puede ser una rutina compilada por fuera, no se si es el caso de firebird.
Saludos: Miguel, La Pampa (RA)

[HernanCano]

Si bien conozco los procedimientos almacenados ("stored procedures"), no me gradan mucho. Los utilicé para auditar registros en una app que estaba fallando y no sabía por qué; al fin de cuentas (tres meses) las fallas no estaban propiamante en las actualizaciones, sino en un diseño errático de la app ((recibir una app de otro no es buen tema)).
Pero alguien te dará mejor apreciación al respecto.

1.
Conozco bien el uso de "Transact SQL", conocido también como "T-SQL". Es lo que en VFP se conoce como "ejecutar comandos con SQLEXEC()".

2.
Cualquiera de las opciones es posible si las manejas bien y no tienes problemas con la que utilices y reconoces las ventajas y aceptas las desventajas (1-conectarse-actualizar-desconectarse; 2-conectarse al inicio de la app, y desconectarse al salir de la app).
Yo te pondría a pensar en si es eficiente hacer la conexión cada vez que necesitas actualizar (eficiente se asocia con rápido). Si para tú es más "seguro" así, debes enfocar tú mismo tu estilo de programación ((tú mismo haces las pruebas, porque preguntar si es adecuado conectarse-actualizar-desconectarse...es evidente que será más lento)). Pero en cuentión de seguridad eres tú mismo quien decide.

--

[Walter R. Ojeda Valiente]

He leído todos los mensajes en este hilo y ahora puedo darte mi opinión.

1. Basicamente tienes tres opciones:
   a. Conectarte a la BD cuanto inicia tu aplicación, ejecutar todos los comandos requeridos, desconectarte al finalizar tu aplicación
   b. Conectarte a la BD cuando ingresas a un formulario, ejecutar todos los comandos requeridos, desconectarte al salir del formulario
   c. Conectarte a la BD cada vez que ejecutas un comando, desconectarte apenas se finaliza la ejecución de ese comando

En todos los casos, antes de ejecutar un comando deberías verificar que la conexión aún se encuentra activa. En el caso de una red LAN eso es lo normal. En el caso de una conexión por Internet no puedes confiar.

Entonces ¿cuál de las tres opciones anteriores es la mejor?

Depende del caso, si todas las computadoras están en una LAN, entonces la 1.a, sin dudas. Para las computadoras que no están allí (por ejemplo, la notebook del Gerente mientras está viajando en un vehículo) la más recomendable suele ser la 1.c aunque por supuesto depende de la estabilidad de la conexión con Internet. Si tiene una buena conexión entonces puedes usar la 1.a también en ese caso.

Tu aplicación debería permitirle al usuario elegir cual de esas tres formas de conexión prefiere (o establecerla tú mismo cuando le instalas tu aplicación)

2. Verificar que la conexión esté activa

Siempre, antes de ejecutar un comando debes verificar que la conexión con el Servidor esté activa, si no lo está entonces:
   a. Intentas reconectarte durante "x" veces o durante "y" segundos
   b. Si fue imposible reconectarte, entonces muestras un mensaje al usuario

3. Para conseguir lo anterior, en lugar de ejecutar la función SQLEXEC() es preferible que crees una función propia o una clase que se encargue de esa tarea. Por ejemplo, la función SQL_Ejecutar():
   a. Verifica que la conexión está activa
   b. Si no lo está, reintenta conectarse varias veces. Si no lo consigue, muestra un mensaje al usuario
   c. Si la conexión está activa, entonces ejecuta la función SQLEXEC()
   d. Devuelve el resultado de la ejecución del comando

4. La velocidad de ejecución también puede ser muy importante, sobre todo en los casos en que hay muchos usuarios concurrentes.
   a. Conectarse a la BD al iniciar la aplicación y desconectarse al finalizar la aplicación es lo más rápido
   b. Conectarse y desconectarse a cada rato consume tiempo y es más lento, aunque no será notorio si el usuario ejecuta pocos comandos

5. El tráfico por la red (o sea, la comunicación entre el Cliente y el Servidor) debe ser el mínimo de todos los mínimos posibles ya que de esa manera garantizarás una acceso muy veloz a los datos. Eso implica:
   a. Que todas tus tablas estén normalizadas
   b. Que nunca consultes más filas de las estrictamente necesarias (cargar un cursor con 100.000 filas para mostrarlas en una grilla es una locura y una ineptitud total porque no habrá persona alguna que leerá tal cantidad de filas)

6. Las transacciones deben ser cortas, lo más cortas posible así:
   a. Minimizas la probabilidad de un corte de conexión mientras se están grabando los datos
   b. Minimizas la probabilidad de un conflicto cuando dos usuarios quieren actualizar la misma fila (porque aunque el Firebird maneja muy bien esta parte, lo hace creando una fila "delta", y la creación de dicha fila tomará algunos milisegundos. Si los conflictos son muy frecuentes entonces la demora puede ser notoria, así que lo mejor es evitarlos)

7. El VFP te permite que las transacciones se graben:
   a. Automáticamente
   b. Manualmente

   Personalmente prefiero grabarlas manualmente, así controlo exactamente el momento y sé lo que está sucediendo, pero es mayormente cuestión de gustos

8. Cuando ejecutas un comando lo puedes hacer:
   a. Sincronicamente
   b. Asincronicamente

Si sabes o sospechas que la ejecución durará mucho tiempo (más de 10 segundos) entonces es preferible que lo hagas asincronicamente y le muestres una barra de progreso o algún otro indicador al usuario, para que éste sepa que tu aplicación está trabajando ya que nunca faltan los idiotas impacientes que pueden creer que se "colgó" tu aplicación

9. No envíes para su ejecución comandos "puros" (algo como: SELECT * FROM CLIENTES) sino utiliza para ello vistas y procedimientos almacenados, eso te dará mucho mayor control sobre lo que cada usuario puede hacer y no hacer, ya que las vistas y procedimientos almacenados pueden ser restringidos de tal manera que solamente los usuarios autorizados puedan ejecutarlos.

10. A los usuarios no les des acceso a las tablas directamente, cualquier operación que quieran realizar con ellas que lo hagan a través de vistas o procedimientos almacenados. Siempre, sin excepción. El único con derecho al acceso directo a las tablas deberías ser tú.

11. Nunca permitas que se inserte basura en las tablas. Para ello, además de tus validaciones en VFP utiliza los triggers, los cuales son buenísimos para validar que solamente los datos correctos sean grabados.

12. Nunca elimines fisicamente una fila que haya sido usada alguna vez. En su lugar es preferible tener una columna que muestre el estado (Activo / Inactivo). Si quieres ser más detallista inclusive puedes grabar también la fecha y hora del cambio de estado, así como el nombre del usuario.

13. Haz backups frecuentes (completos o incrementales) de tu BD y guárdalos en otra habitación, no en la habitación donde se encuentra el Servidor.

14. Si no todas las computadoras están en una LAN entonces debes tener un mecanismo de replicación. Por ejemplo cuando:
   a. Hay computadoras en ciudades diferentes o en barrios diferentes
   b. Hay alguien con una notebook fuera del local de la empresa

15. No utilices shadows, están obsoletos, la replicación es preferible.

Creo que esos son los lineamientos generales, si tienes alguna duda, sólo pregunta.

Saludos.

Walter.

---

Date: Mon, 11 Jun 2012 19:05:23 -0700
From: jherna...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Re: Como se trabaja con VFP-Firebird u otros SGBD? Qué es lo mas recomendable..

[Fox Learner]

Excelente! Eso es lo que quería saber. Gracias señores por las clases.

Hernan,

Solo pregunto cual es mas recomendable para evitar perder mucho tiempo
haciendo pruebas.

Lo que sucede es que "leo mucha información" en los manuales de VFP
que me doy cuenta que ya no es aplicable.

2 ejemplos de esto son : 1. El uso de numeros de areas como SELECT 2

El manual del programador está repleto de ejemplos usando numeros de
area. Sin embargo, ahora sé que eso ya no se usa y que fue algo que
aun se conserva para el control interno del vfp o para
"compatibilidad" con sistemas basados en DOS.

2. El uso de formset. Tambien viene en los manuales, pero al parecer
existen formas mas sencillas y practicas de evitar meterse en todo ese
"merequetengue" jeje

En fin, que para VFP ya he dejado de creer en mucho de lo que dicen
los libros. Por eso mejor pregunto a quienes lo usan, y saben algunas
técnicas que resultan prácticas.

Además, VFP parece tener bastantes trucos ocultos, que no me
extrañaría que hasta trajera algo como el excel 97 (un juego oculto
que se activa al presionar una combinacion de teclas) jeje

En fin, todas estas explicaciones son muy esclarecedoras y agradezco
el tiempo invertido en ellas.

Saludos!

[Fox Learner]

Ahora, sobre lo que comenta Walter sobre no presentar un "bonche" o
monton de registros (filas en FB).

Estoy viendo que el MySql usa una sentencia algo así como:

LIMIT 0, 30

Me dice el profesor que esto es para "paginar" la cantidad de
registros que se mostrarán por pagina, tal como lo hace el google en
cierta busqueda, supongo.

Si se usa ese LIMIT se logra alguna ventaja o de plano no sería
recomendable para un sistema de escritorio tipo LAN?

Veo que para la web, tal vez sea una opción, pero para Desktop sobre
LAN?...

Gracias!

[Geovanny Quirós Castillo]

Hola,

Para mi lo idoneo es trabajar siempre con procedimientos almacenados, dejarle al motor el trabajo con los datos y a la aplicación las demás cosas,

 

Fox Learner, me muevo bien con SQL Server y por lo tanto hablaré sobre el, supongo que FireBird o Mysql trabajan de manera similar.

Te daré un ejemplo muy básico de como trabajar con SPs desde fox.

 

Primero, creamos un procedimiento almacenado en el sql

 

USE [clientes]

go

Create procedure SP_ConsultarUnCliente

        @cedula int

with encryption

as

begin

  begin try

        select cedula,nombre,saldocred from clientes where cedula=@cedula

  end try

  begin catch

        print 'El siguiente error a sucedido :' +ERROR_MESSAGE()

  end catch

end

 

La clausula “with encryption” hace que el SP se guarde encriptado en el servidor y el código que contiene no será visible ni modificable por nadie.

 

Segundo, invocamos el SP desde fox:

 

TEXT TO SQLCMD NOSHOW

    EXEC SP_consultarUnCliente ?mcedula

ENDTEXT

SQLEXEC(XMConectaSql,SQLCMD,cursor_clientes)

 

Y listo los datos del cliente quedan en el cursor cursor_clientes  para que hagas con el lo que quieras.

 

Saludos

Geovanny.

[Fox Learner]

Geovanny, Te agradezco la explicación y el código de ejemplo. Saludos!

[extremo]

FoxLearner

Quien te dijo que los numeros de area no se usan?.... siempre se usan
y sin ellos no puedes trabajar. Te doy un ejemplo

Select usuarios in 0
select usuarios

internamente el VFP ubica el cursor en una area de trabajo disponible,
si es la primera tabla, entonces la dejara en el uno.

sqlexec(miConn ,"select * from usuarios" ,"MiCursor")
internamente el VFP ubica el cursor en una area de trabajo disponible,
como es la segunda, entonces la dejara en el dos.


ahora para llamar la primera area puedes usar una de las siguientes
formas
select 1
o
select usuarios

Para llamar al segundo cursor:
select 2
o
select MiCursor

En particular prefiero llamr mis areas de trabajo con sus nombres ya
que es mas legible para revisar un codigo. Pero esto no significa que
los numeros de areas no se usen, simplemente usas su alias. El que te
dijo que estaban obsoletas o que se usan para compatibilidad con
sistemas DOS, simplemente no sabe lo que dice o tu le entendistes mal.

Bendiciones

[Fox Learner]

Extremo,

Me lo dijo el Maestro Luis Maria y muchos otros.

Y lo que comentas es la forma como él y muchos otros recomiendan usar
las areas para dejar que Fox haga "el trabajo sucio". Una de las forma
recomendadas es:

Select Mitabla IN 0
Select Mitabla

No sería recomendable usar los números ya que uno se pierde si tenemos
por ejemplo unas 80 tablas.

Tambien sé que es cómodo usar el nombre de la tabla que es el mismo
nombre del alias, para evitar usar los molestos alias.

Por qué no me respondes lo que pregunte de MySql sobre el LIMIT 0,
30?...

Recuerdo que tu eres uno de los buenazos en MySql y has comentado que
en Chile o algo así no les falla conexión a internet.

Recuerdo que comentaste que prefieres MySql sobre Firebird debido a
que tiene soporte mas competitivo (en cuanto a precios y popularidad)
en los "hostings.

Saludos!

[Miguel Antúnez]

por lo personal me olvide de los nombres de los cursores y mas aun los select 0, select 1 , etc.

 

a mis cursores les genero nombres aleatorios.

Saludos.

[extremo]

No, no soy buenazo en mysql, se solo algunas cosas, lo que mas uso es
SqlServer. Sobre LIMIT es tal como dices, es para paginar. Se puede
utilizar sin problemas en una LAN (el limit puede cambiar, no
necesariamente debe ser 30). Lo recomendable es que si se use en SGBD
que sean medianas o grandes (mas de 1 GB) ya que con eso evitas traer
mucha informacion y evitas que la red se sature. En mi caso, yo no lo
uso ya que la cantidad de registros a traer lo controlo en el mismo
programa.

Bendiciones

On 12 jun, 14:26, Miguel Antúnez <mantun...@gmail.com> wrote:
> por lo personal me olvide de los nombres de los cursores y mas aun los
> select 0, select 1 , etc.
>
> a mis cursores les genero nombres aleatorios.
>
> Saludos.
>

> El 12 de junio de 2012 13:12, Fox Learner <thenewinquire...@gmail.com>escribió:
>
>
>
>
>
>
>
>
>
> > Extremo,
>
> > Me lo dijo el Maestro Luis Maria y muchos otros.
>
> > Y lo que comentas es la forma como él y muchos otros recomiendan usar
> > las areas para dejar que Fox haga "el trabajo sucio". Una de las forma
> > recomendadas es:
>
> > Select Mitabla IN 0
> > Select Mitabla
>
> > No sería recomendable usar los números ya que uno se pierde si tenemos
> > por ejemplo unas 80 tablas.
>
> > Tambien sé que es cómodo usar el nombre de la tabla que es el mismo
> > nombre del alias, para evitar usar los molestos alias.
>
> > Por qué no me respondes lo que pregunte de MySql sobre el LIMIT 0,
> > 30?...
>
> > Recuerdo que tu eres uno de los buenazos en MySql y has comentado que
> > en Chile o algo así no les falla conexión a internet.
>
> > Recuerdo que comentaste que prefieres MySql sobre Firebird debido a
> > que tiene soporte mas competitivo (en cuanto a precios y popularidad)
> > en los "hostings.
>
> > Saludos!
>
> --
> Miguel Angel Antúnez Camones

> mantun...@gmail.com

[Fox Learner]

Ups! Me equivoqué en mi mensaje anterior. Dije:

Una de las forma recomendadas es:
Select Mitabla IN 0
Select Mitabla

Era:

USE Mitable IN 0
Select Mitabla

Perdon por el error de dedo jeje