Re: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Douglas Sánchez Guillén]

Lo que te recomiendo es que trabajes con Transacciones asi no tendras problemas con datos con cabeza y sin pies. 

y lo de los apagones ya he pasado eso y nunca almenos a mi no se me ha dañado una tabla ni de sql server que solo tengo dos sistemas y menos de msyq server q tengo 5 Sistemas, 

saludes

El 6 de mayo de 2011 15:29, Easy Gestion <flo2...@gmail.com> escribió:

Hola Grupo, saludos a todos.

Mi pregunta apunta a los que utilizan algun tipo de motor base de datos, como puede ser MySql, SQL Server, etc.

He leido en este mismo foro que en entorno de Red Local y clableda, deberia iniciarse la aplicación y conectarse a la base de datos y quedar simpre activa, hasta que se cierre la aplicación, pero mi consulta es: En caso de cerrarse la aplicación en forma NO normal, corte de luz por ejemplo, o por alguna otra causa, se dañaria la base de datos?, las tablas?, se dañan las bases de datos y tablas de MySql? , de ser así como se reparan o que hay que tener en cuenta para que esto no suceda?

Desde ya muchas gracias por sus comentarios.

Atte.

Gabriel

--
Ing. Douglas Sánchez Guillén

      Consultor Informatico

Movistar: 505 8759 - 5342

Claro: 505 88495476

[Walter R. Ojeda Valiente]

En Firebird no se dañan, como máximo se podrían perder los datos a los cuales no se les hizo el COMMIT, todos aquellos que fueron "commitados" se quedan grabados permanentemente.

En otras bases de datos sí pueden dañarse e inclusive corromperse la Base de Datos.

Saludos.

Walter.

---

Date: Fri, 6 May 2011 18:29:46 -0300
Subject: [vfp] [VFP] Conexion Permamnte o NO a MySQL?
From: flo2...@gmail.com
To: publice...@googlegroups.com

[Jose Oscar Vogel]

en MySQL no creo que tan facil se corrompan, a mi me paso que varias veces se corto la luz y nunca tuve inconvenientes con MySQL, todo buen gestor de base de datos debe considerar el recupero por una falla, de todas formas el servidor de base de datos debiera tener una UPS para los casos en que se corte la luz.

Saludos Oscar

--
Prof. Jose Oscar Vogel
Garuhapé - Misiones
CP 3334
Cel: 03743-15667526

MSN: oscar...@gmail.com
Twitter: @ovogel23
Facebook: oscarvogel

[lm...@cclf.com.pe]

Yo trabajo con la conexión permanente, cualquier apagón, reseteo puede dañar la BD, la idea es estar prevenidos ante estos casos, una batería en caso de cortes de luz con duración de mínimo 2 horas, copias de seguridad ante posibles desastres.. esto seria lo mas importante, debes de asegurar la información ósea el servidor al 100%, las pc del cliente son menos relevantes pero si puedes protegerlas también hazla.

 

Luis Mata

 

From: Easy Gestion

Sent: Friday, May 06, 2011 4:29 PM

To: publice...@googlegroups.com

Subject: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

 

[Easy Gestion]

[Alfonso Arias Lemas]

Oi, yo uso SQL Server hace como 4 años en varios clientes y si te digo que se ha dañado en ese periodo 1 ó 2 veces la(s) base de datos creo sea mucho, siempre que garantices el servidor la aplicación puede reventar que no pasa nada, ahora si el servidor esta desprotegido entonces otro gallo cantaria. Sugerencia, atender el servidor mas que cualquier elemento del sistema y si estan todos los movimientos, SP y query de las bases de datos con transacciones no hay problemas.

Saludos,

    Alfonso 

---

De: Walter R. Ojeda Valiente <wr...@hotmail.com>
Para: publice...@googlegroups.com
Enviado: vie,6 mayo, 2011 20:39
Asunto: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Easy Gestion]

Gracias a todos por sus comentarios.

Tube la inquietud de consultarlos ya que mi sistema desarrollado en VFP  9 + SQL Server Express, sera utilizado en equipos que NO van a tener UPS, y ademas los usuarios son totalmente descuidados y NO siguen los pequños tips que se les dan, es decir apagan sus computadoras sin cerrar el sistema e incluso sin cerrar windows, directamente del boton del equipo, pero con lo que han dicho ya puedo realizar ciertas rutinas para tratar de evitar los futuros problemas.

Gracias a todos nuevamente.

Gabriel

[Miguel Antúnez]

No por eso debemos de quedarnos de las manos cruzadas, los usuarios no deben ser impedimento para que nuestro software sea seguro.
Recomendaciones el ups no es necesario a los usuarios solo al server.
Otro tener una programacion de backups segun los movimientos que tengas puede ser un full de noche y uno o dos transaccionales en el dia.
El server por loo menos que maneje discos espejo.

Saludos.

Desde mi Android

El 7/05/2011 6:42, "Easy Gestion" <flo2...@gmail.com> escribió:

Gracias a todos por sus comentarios.

Tube la inquietud de consultarlos ya que mi sistema desarrollado en VFP  9 + SQL Server Express, sera utilizado en equipos que NO van a tener UPS, y ademas los usuarios son totalmente descuidados y NO siguen los pequños tips que se les dan, es decir apagan sus computadoras sin cerrar el sistema e incluso sin cerrar windows, directamente del boton del equipo, pero con lo que han dicho ya puedo realizar ciertas rutinas para tratar de evitar los futuros problemas.

Gracias a todos nuevamente.

Gabriel

El 6 de mayo de 2011 22:20, Alfonso Arias Lemas <arias...@yahoo.es> escribió:

>
> Oi, yo uso SQL Server hace como 4 años en varios clientes y si te digo que se ha dañado en ese ...

[Carlos Miguel FARIAS]

Estimado Gabriel, por lo que vale una ups (800$ (en argentina para 4 pc, para 10 minutos de corte) no tener protegido el servidor es una idiotez total. O sea que si queres olvidarte de perdida por cortes de luz en el servidor (que puede ser el servicio muy bueno pero el que limpia muy torpe y desenchufarte todo), asegurate con una UPS.
Por muy bueno que sea el SGBD, ante un corte de luz, se hace desastre, porque ante falla electrica, no solo importa el SGBD si no que entra a jugar como esta configurado el SO (buffers y demas) que pueden hacer un desastre y el sgbd ni enterado y no recupera.

[Guillermo MDQ]

Gabriel, si tus usuarios son descuidados, y ni siquieran cierran el
sistema y el windows para apagar el equipo, directamente deciles que
no podes garantizarle la integridad de los datos.
Yo siempre se los planteo de esa forma, y si no lo quieren entender,
despues de un par de veces que pierdan los datos vas a ver como siguen
tus consejos.

Saludos
Guillermo
Mar del Plata, Argentina

[Victor Espina]

Creo que estamos mezclando dos conceptos distintos:

1. Corrupción de datos por falla catastrófica.  Esta situación no depende de si se esta usando una única conexión permanente con la BD o de si se abre una nueva conexión cada vez que se necesita acceder al servidor.  Los programadores de VFP tenemos un trauma que asocia automaticamente caida del sistema con corrupcion de datos. Pero como han comentado casi todos aca, esto rara vez pasa con servidores como SQL Server y MySQL. Este tipo de ambientes, el problema principal es la integridad de los datos; es decir, que si un proceso que involucraba la actualizacion de varias tablas finaliza de forma inesperada, la BD quedaria en un estado inconsistente.  La forma de evitar esto es el uso de transacciones, las cuales garantizaran que o bien se guardan todos los cambios realizados desde el inicio de la transaccion o no se graba ninguno, y esto es valido tanto si usamos una conexion permanente como si no,

2. Utilizacion de las conexiones al servidor. Utilizar una sola conexion con la BD durante el tiempo que dure la sesion del usuario con el sistema parece una idea logica y sencilla. Sin embargo, tiene serios inconvenientes que, al menos en mi opinion, la hacen una idea terrible:

a) Consumo de recursos del servidor: cada conexion abierta con el servidor consume recursos de memoria en el mismo. Esto quiere decir que si nuestro sistema es usado por 50 usuarios al mismo tiempo, estariamos hablando de 50 conexiones abiertas en el servidor consumiendo recursos continuamente.

b) Latencia en conexiones de area grande: si estamos en una red local, esto no es un problema. Pero en el instante que nuestro cliente quiera conectarse al sistema desde fuera de la red, se convierte en un problema serio ya que sera mucho mas probable que la capa ODBC genere un error de timeout sobre la conexion al momento de intentar utilizarla. 

Dado que pasar del modelo de conexion unica al modelo de conexion-justo-a-tiempo no es algo sencillo, creo que es preferible enfocarlo de esta manera desde el principio: cada vez que se necesite hacer algo con el servidor, se aplica esta regla:

a) Me conecto con el servidor

b) Si no me pude conectar, muestro un mensaje y cancelo el procedimiento

c) Envio una o mas instrucciones al servidor

d) Cierro la conexion

Tambien es MUY importante no introdudir situaciones de wait-state dentro de este ciclo, sobre todo si estamos en medio de una transaccion, ya que esta es la mejor manera de crear situaciones de dead-lock en el servidor.

En conclusion, aplicando una estrategia de conexion-justo-a-tiempo no solamente permitimos que nuestro sistema pueda ser usado perfectamente tanto en redes LAN como WAN, sino que reducimos drasticamente el consumo de recursos en el servidor de datos.

Saludos

Victor Espina

[Walter R. Ojeda Valiente]

Hola Víctor

Mi estrategia es distinta:

- Me conecto a la Base de Datos al inicio de la aplicación
- Cuando se envía un comando para realizar una operación en ella (insert/delete/update/select) lo primero que se hace es verificar que la conexión esté activa
- Si está activa, se ejecuta el comando
- Si no está activa, se trata de reconectar a la Base de Datos. Si después de 30 intentos no se consiguió reconectar (entre cada intento transcurren 2 segundos) entonces se le avisa al usuario.
- Al salir de la aplicación me desconecto de la Base de Datos

Ese es el procedimiento normal, pero también tengo la opción configurable por el usuario de:
- Conectarse a la Base de Datos
- Ejecutar la operación
- Desconectarse de la Base de Datos

La cual se debería emplear solamente cuando hay frecuentes caídas de la conexión (quizás porque está viajando con una notebook).

Elegir entre un procedimiento o el otro es solamente cambiar el valor de una propiedad de la clase SQL_Database:

lTerminarConexión (si es .T., ejecuta el comando y se desconecta de la Base de Datos. Si es .F., ejecuta el comando y no se desconecta).

Saludos.

Walter.

---

Date: Sat, 7 May 2011 10:11:10 -0700
From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[sergio garcia]

Yo utilizo la misma estrategia de Walter y no tengo problemas y así evitas tener varias conexiones y si se cae alguna maquina no siguen abiertas tantas conexiones.

 

 

 

 

______________________________________

Desarrollos de software

E-mail:    gere...@magicsoft.com.gt

Aletrnativo: in...@magicsoft.com.gt

Web:      www.magicsoft.com.gt

__________ Información de NOD32, revisión 6102 (20110507) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com

[Victor Espina]

Walter, pero pasas por alto el tema del consumo de recursos. Es mas eficiente crear una conexion solo cuando se necesite y liberarla despues (lo cual libera memoria en el servidor que puede entonces ser usada para otra cosa), que tener decenas de conexiones abiertas que pudieran no estar haciendo nada mas que consumir recursos en el servidor por varios minutos o incluso horas.

Saludos

Victor 

[Walter R. Ojeda Valiente]

Hola Víctor

Es cierto, pero con las computadoras que tenemos ahora, con una inmensa cantidad de RAM disponible, la memoria que se usa para mantener una conexión abierta es casi despreciable. Por ejemplo, con Firebird se usa 1 Mb para 8 conexiones. O sea que con 100 Mb puedo tener 800 conexiones abiertas. ¿Y qué son 100 Mb para un Servidor en esta época? Practicamente nada.

Y si una empresa necesita tener 800 conexiones o más, comprar unos cuantos Gigabytes más de RAM para el Servidor no le causará un perjuicio económico, es más, será una suma totalmente despreciable frente a los números que están acostumbrados a manejar.

Además, eso de estar abriendo y cerrando conexiones toma su tiempo. Si el usuario debe realizar muchas tareas tantas aperturas y cierres harán que su aplicación funcione más lentamente de lo que debería ¿vale la pena proveerle de una aplicación lenta sólo para ahorrar unos pocos Kb en el Servidor?

Mi criterio es que generalmente, no.

Lo que tú dices era un punto importante a considerar hace varios años, cuando la memoria era cara y por lo tanto aún los Servidores contaban con poca cantidad de ella, pero ya no es el caso actualmente.

Saludos.

Walter.

---

Date: Sat, 7 May 2011 15:41:49 -0700
From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Walter Valle]

Hola Walter y Víctor,

De acuerdo con mi tocayo... antes usaba la técnica de Víctor. Pero no
vi un beneficio tan real o que redujera mucho el consumo de CPU y RAM
en SRV, pero es mucho mejor tener esa conexión viva y verificarla...
el impacto en SQL Server no es muy significativo. Mi app principal la
usan 85 conexiones vivas en las horas pico... y jamas tengo problemas
de performance. Aunque debo decir que tengo un server Dell con 8 GB de
RAM y 2 procesadores. Lo mas que consume en esas horas, son 2.7 GB de
RAM a máximo rendimiento.(SO y DB)

Saludos!


Walter Valle

On 7 mayo, 16:57, "Walter R. Ojeda Valiente" <w...@hotmail.com> wrote:
> Hola Víctor
>
> Es cierto, pero con las computadoras que tenemos ahora, con una inmensa cantidad de RAM disponible, la memoria que se usa para mantener una conexión abierta es casi despreciable. Por ejemplo, con Firebird se usa 1 Mb para 8 conexiones. O sea que con 100 Mb puedo tener 800 conexiones abiertas. ¿Y qué son 100 Mb para un Servidor en esta época? Practicamente nada.
>
> Y si una empresa necesita tener 800 conexiones o más, comprar unos cuantos Gigabytes más de RAM para el Servidor no le causará un perjuicio económico, es más, será una suma totalmente despreciable frente a los números que están acostumbrados a manejar.
>
> Además, eso de estar abriendo y cerrando conexiones toma su tiempo. Si el usuario debe realizar muchas tareas tantas aperturas y cierres harán que su aplicación funcione más lentamente de lo que debería ¿vale la pena proveerle de una aplicación lenta sólo para ahorrar unos pocos Kb en el Servidor?
>
> Mi criterio es que generalmente, no.
>
> Lo que tú dices era un punto importante a considerar hace varios años, cuando la memoria era cara y por lo tanto aún los Servidores contaban con poca cantidad de ella, pero ya no es el caso actualmente.
>
> Saludos.
>
> Walter.
>

> Date: Sat, 7 May 2011 15:41:49 -0700

> From: vespi...@gmail.com

[Richard Gaviria]

Hola a todos casi no tengo tiempo para el foro, pero quería responder esta pregunta.

El mantener la conexión abierta no es cuestión de consumir más o menos recursos, el tema está en mantener una vía abierta hacia la base de datos. Ahí tienes un problema que en todas las bases de datos se llama "conexión latente", esto representa un peligro de seguridad.

En general en todos los grandes sistemas basados en transacciones el sistema se conecta cuando va a realizar una transacción y se desconecta cuando termina.

Las experiencias que tengo en SAP y otros sistemas que usan Oracle y MySql señalan que la conexión solo se debe abrir al realizar una transacción y cerrar cuando termina la misma.

Saludos.

Rick.

hhtp;//www.engineersoftasociados.com

> Date: Sat, 7 May 2011 17:44:06 -0700
> Subject: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?
> From: wva...@gmail.com
> To: publice...@googlegroups.com

[Walter R. Ojeda Valiente]

Hola Richard

En primer lugar, lamento que no tengas más tiempo para escribir en el grupo, tus aportes siempre son importantes.

En segundo lugar, aunque mantener la conexión abierta conlleva un cierto riesgo de seguridad, hay que sopesarlo contra el aumento en la velocidad de acceso que se obtiene. En aplicaciones críticas (Bancos, por ejemplo) lo que tú dices puede ser lo recomendable, pero ¿se debe aplicar ese mismo criterio a las empresas comunes? Opino que no.

En todo caso, se podría implementar una solución intermedia: mantener la conexión abierta y si en un tiempo "x" (5 minutos, por ejemplo) el usuario no realizó alguna operación entonces cerrarla. De esta manera si está realizando operaciones intensivas (como cargar los datos de muchos clientes de una sola vez) eso no hará que su tarea le resulte interminable con tantas esperas.

Saludos.

Walter.

---

From: rgav...@msn.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?
Date: Sun, 8 May 2011 01:01:47 +0000

[Richard Gaviria]

Bueno, es cierto que uno puede "acomodar" el uso de un sistema de acuerdo a los factores que nos rodean.

Por ejemplo si se sabe que la red "nunca falla" (lo cual es muy dificil de lograr) se puede mantener una conexión abierta.

Realmente la conexión y desconexión no es un factor que deba consumir mucho tiempo en tu aplicación a menos que tu base de datos esté en un servidor web.

Yo ya he tenido amargas experiencias con "conexiones latentes" que conllevaron en pérdida de datos.

Saludos.

Rick.

hhtp://www.engineersoftasociados.com

[Walter R. Ojeda Valiente]

Bueno, supongo que dependerá de cual motor estés utilizando, en el caso de Firebird después del COMMIT puedes estar segurísimo que los datos se grabaron en el disco duro y que permanecerán allí, sin importar los cortes de energía eléctrica o las caídas de conexión.

Yo tengo clientes que son muy quisquillosos con el tema del tiempo perdido. Inclusive han hecho cálculos del tipo: "si en cada operación se pierden 2 segundos y hay 300 operaciones por día y por usuario y tenemos 12 usuarios, entonces al final del día tenemos 2 horas perdidas, al final del mes tenemos 48 horas perdidas y al final del año 576 horas perdidas, lo cual equivale a tres meses de trabajo de una persona".

Entonces, ahorrarles 2 segundos por cada operación es muy valioso económicamente.

Saludos.

Walter.

---

From: rgav...@msn.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?

Date: Sun, 8 May 2011 01:36:31 +0000

[Miguel Antúnez]

Nunca pude determinar ventaja o desventaja de tener abierta una conexion, lo que dice walter es falso, no se gana rapidez al conectarse y desconectarse por cada transaccion, sl final lo que mas me convence es la seguridad asi que me inclino hacia eso. Abrir y cerrar la conexion por cada transaccion. Y mi capa de conexion tiene ademas la posibilidad de no hacerlo. Solo si encontrara una razon mas valedera para hacerlo.

Saludos.

Desde mi Android

El 7/05/2011 20:56, "Walter R. Ojeda Valiente" <wr...@hotmail.com> escribió:

Bueno, supongo que dependerá de cual motor estés utilizando, en el caso de Firebird después del COMMIT puedes estar segurísimo que los datos se grabaron en el disco duro y que permanecerán allí, sin importar los cortes de energía eléctrica o las caídas de conexión.

Yo tengo clientes que son muy quisquillosos con el tema del tiempo perdido. Inclusive han hecho cálculos del tipo: "si en cada operación se pierden 2 segundos y hay 300 operaciones por día y por usuario y tenemos 12 usuarios, entonces al final del día tenemos 2 horas perdidas, al final del mes tenemos 48 horas perdidas y al final del año 576 horas perdidas, lo cual equivale a tres meses de trabajo de una persona".

Entonces, ahorrarles 2 segundos por cada operación es muy valioso económicamente.

Saludos.

Walter.



________________________________
From: rgav...@msn.com

To: publicesvfoxpro@g...

Date: Sun, 8 May 2011 01:36:31 +0000

Bueno, es cierto que uno puede "acomodar" el uso de un sistema de acuerdo a los factores que nos r...

[Jose Oscar Vogel]

Si t fijas en los benchmark de coneccion y desconeccion de MySQL veras q el 30% del tiempo significa del total del tiempo de una transaccion
Saludos Oscar

El may 8, 2011 10:30 a.m., "Miguel Antúnez" <mant...@gmail.com> escribió:

Nunca pude determinar ventaja o desventaja de tener abierta una conexion, lo que dice walter es falso, no se gana rapidez al conectarse y desconectarse por cada transaccion, sl final lo que mas me convence es la seguridad asi que me inclino hacia eso. Abrir y cerrar la conexion por cada transaccion. Y mi capa de conexion tiene ademas la posibilidad de no hacerlo. Solo si encontrara una razon mas valedera para hacerlo.

Saludos.

Desde mi Android

El 7/05/2011 20:56, "Walter R. Ojeda Valiente" <wr...@hotmail.com> escribió:

> Bueno, supongo que dependerá de cual motor estés utilizando, en el caso de Firebird después del CO...

[Ricardo Pina]

Las dos formas de trabajo son válidas y tienen defensores "peso pesado", asi que repasando lo escrito, yo haría la diferencia en el entorno en el cual está funcionando el sistema.

En una LAN pequeña o mediana el esquema de conexión permanente sería lo mejor y en grandes redes o redes inalambricas usaría conexión/desconexión a nivel transacción.

 

Saludos

--
Ricardo Pina
D&SIP
Desarrollo y Servicios Informáticos Profesionales
www.dsip.com.ar

[Arnaldo Toledano]

Muy Interesante el tema.
Creo que podríamos sacar una conclusión a modo de "manual" para el caso.
Ahora bien, yo veo que para los neófitos, en los cuales me incluyo, es necesario aclarar ciertos puntos.
1.- Para conectarme a una base de datos de MySQL y creo que a todas, por lo general se utiliza el siguiente código.

1.1.-  SQLCONNECT(Datos necesarios, Tipo, Usuario, Clave)

1.2.-  SQLEXEC(Con_Quien_Estoy_Conectado,Sentencia_Select_O_LoQueSea,....) < Según el caso, 0,1

1.1.- Con la primer instrucción estoy CONECTADO a la base de datos.
Pero ello no significa que tenga TODAS las tablas abiertas.
Simplemente tengo un canal de CONEXIÓN.

1.2.- Realizo una operación especifica con una o X tablas de la conexión abierta.

2.- De acuerdo a lo que he leído, MySQL, maneja Bufer de 64 K, cuando este es llenado se baja al servidor.
Por lo que deduzco  es que ante cada operación seria necesario hacer un COMMIT para asegurarnos que los datos fueron bajados al servidor.
Este commit es muy particular para cada EMPRESA.
En mi caso, tengo definido el commit como un parámetro.
De esa manera realizo el COMMIT en función del entorno que tengo, puesto que a veces demasiados commit hacen muy lenta la red.
Pero...  algunos clientes son tan descuidados que no queda otra que hacerlo.

De paso les comento que para aquellos clientes que son reacios a comprar UPS, tengo un argumento que siempre me ha sido útil.
"Con la perdida de X registros de CTA.CTE. (según el caso), estoy recuperando el gasto de una UPS"
En el caso de facturaciones mínimas de U$S 250.00 por cliente, con UN SOLO REGISTRO recupero el gasto.

3.- Ahora bien.
Este es el "problema".
3.1. ¿Es necesario CERRAR LA CONEXIÓN con la base de datos cada vez que termino una operación ?
Para el caso de una empresa donde la conexión es por cable y si nos atenemos a lo que dice MySQL que soporta 100+1 Conexiones simultaneas por defecto.
Creo que NO.
http://dev.mysql.com/doc/refman/5.0/es/too-many-connections.html

Para el caso de CONEXIONES REMOTAS.
Creo que si es NECESARIO cerrar la conexión,

Ahora bien.
En el caso de CERRAR la conexión en una red interna y CABLEADA.

3.2. ¿En que momento realizo la CONEXIÓN?
3.2.1. Al momento de abrir un FORMULARIO
3.2.2. Al momento de utilizar una TABLA.



Espero haber sido claro y que aquellos que tienen mas experiencia en el caso me puedan aclarar las dudas y corregir  errores.

Gracias al GRUPO.

Arnaldo Toledano
Córdoba
Argentina

--
Arnaldo Toledano Tesys Informática Córdoba Argentina

[Walter R. Ojeda Valiente]

Entendiste mal, yo no dije que se ganaba rapidez al conectarse y desconectarse sino al conectarse una sola vez (al inicio de la aplicación) y desconectarse una sola vez (al final de la aplicación).

Saludos.

Walter.

---

Date: Sun, 8 May 2011 08:30:34 -0500
Subject: Re: RE: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?
From: mant...@gmail.com
To: publice...@googlegroups.com

[Walter R. Ojeda Valiente]

Según mi criterio, lo mejor es lo siguiente:

- Conectarse en forma permanente, por defecto
- Darle a cada aplicación (y usuario, por supuesto) la posibilidad de conectarse permanentemente o por cada transacción.

Así, si tiene problemas con su conexión o la seguridad es asunto crítico puede optar por conectarse por cada transacción.

Y en general, si está en su oficina con su computadora de escritorio tendrá una conexión permanente pero si está fuera de su oficina con su notebook y conexión por Internet puede conectarse una vez por cada transacción.

Las redes inalámbricas no son aconsejables para aplicaciones de Bases de Datos pero si hay que usarlas sí o sí entonces probablemente lo mejor sea conectarse por cada transacción.

Saludos.

Walter.

---

From: ric...@gmail.com
Date: Sun, 8 May 2011 10:59:17 -0300
Subject: Re: RE: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?
To: publice...@googlegroups.com

[Walter R. Ojeda Valiente]

Hola Arnaldo

Sí, es lo correcto, al conectarte a una Base de Datos lo que tienes es un canal abierto para comunicarte con ella, nada más.

Si no haces un COMMIT y se corta la conexión con la Base de Datos (por el motivo que sea) los datos que estaban en el buffer generalmente se pierden, la única alternativa suele ser volver a cargarlos.

Los COMMIT implican grabación permanente en el disco duro por lo tanto es lógico que muchos COMMIT hagan lenta a la red. Pero si no haces un COMMIT puedes perderlos a todos, así que en algún momento debes hacer el COMMIT.

De todas maneras, eso depende del motor de Base de Datos que estás utilizando, en el caso de Firebird hacer un COMMIT es solamente cambiar el valor de una bandera así que el tiempo perdido es ínfimo.

Como ya escribí en otros e-mails, mi criterio es que la conexión debe permanecer abierta en una red local y abrirse/cerrarse solamente en el caso de frecuentes caídas de conexión o cuando el tema de la seguridad sea crítico.

Si vas a usar conexión a la Base de Datos por cada transacción entonces debes realizarla en el momento mismo de la transacción, nunca antes. Por ejemplo abrir la conexión al momento de abrir el formulario no tiene sentido, ya que sería lo mismo que tener una conexión permanente. Si un usuario tiene un formulario abierto durante 8 horas entonces tendría la conexión con la Base de Datos abierta durante 8 horas.

Lo correcto entonces sería:
- Abrir la conexión con la Base de Datos
- Realizar la operación deseada (insert/delete/update/select)
- Cerrar la conexión con la Base de Datos.

En SQL_DEMO se muestra como hacer esto. Es simplemente cambiar el valor de la propiedad "lTerminarConexion" para conectarte de una forma o de la otra.

Saludos.

Walter.

---

Date: Sun, 8 May 2011 13:20:26 -0300
From: arnaldo....@gmail.com
To: publice...@googlegroups.com
Subject: Re: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?

[lm...@cclf.com.pe]

El consumo de recursos es mínimo , si desconectas y conectas tu aplicación lo limitas a solo trabajar de manera local, que que cuando lo trabajas de manera remota, eso se vuelve recontra pesado, es mas del doble de tiempo una transacción al tener que conectar y desconectar y si las transacciones son fluidas prepárate para que te tiren el sistema al tacho o te hagan carga montón.

En una red local tener la conexión activa no debería de representar ningún problema, pero tampoco decir que no es apropiado conectar y  desconectar por Ej. ese tipo de transacciones lo usaria en los cajero automaticos o de similares transacciones.

 

From: Victor Espina

Sent: Saturday, May 07, 2011 5:41 PM

To: publice...@googlegroups.com

[Victor Espina]

Walter no concuerdo contigo. Independientemente de si estas en una red LAN o una red WAN, cada conexion que se abre con el servidor de datos involucra una cierta cantidad de memoria que se reserva en el servidor para manejar el trafico que va y viene por esa conexion.  Esa memoria estara activa y en uso todo el tiempo que la conexion permanezca abierta.

Por otra parte, no es cierto que abrir una conexion tome un tiempo considerable; eso es cierto SOLO para la primera conexion, despues de lo cual las siguientes conexiones son practicamente instantaneas, al menos en una red local. En una red WAN es cierto que establecer la conexion puede tomar mucho mas tiempo que en una red local, pero aun asi se sigue aplicando el mismo principio: la primera conexion es la que tomara mas tiempo, mientras que las restantes tomaran un tiempo mucho menor.

Por ultimo, de que forma usar un esquema de conexion por demanda me limita solo a redes locales?  mas bien es lo contratio: usar un esquema de conexion continua me limita a poder funcionar solo en una red local, mientras que el esquema de conexion por demanda me permite funcionar tanto en red local como en remota.

Saludos

Victor Espina

[Carlos Miguel FARIAS]

Yo me he conectado a bd en la web (servidor web) desde vfp y el tiempo de conexion mas un cursor de 40/50 registros, los recuperaba casi como si fueran nativas de vfp (y la conexion era desde maquinas relativamente pequeñas)

[Easy Gestion]

Victor, estoy de acuerdo con tu forma de programar, es más uno de mis sistemas trabaja de esa forma, conecto cuando es necesario y desconecto, y la primera conexion siempre la hago cuando se ingresa al sistema con usuario y contraseña, ya que es la primera demorará un poco más, luego casi se se nota la diferencia, Mi pregunta apuntaba a un esquema de computadoras y "humanos" realmente dificiles de llevar, ya que trabajan en 7 terminales, pcs bastantes antiguas y procesan cada una unos 20000 registros al dia.

Las formas en realidad son de cada quie, pero siempre es bueno consultar y obtener estos valiosos comentarios.

Saludos a todos

Gabriel

El 9 de mayo de 2011 14:42, Victor Espina <vesp...@gmail.com> escribió:

[Walter R. Ojeda Valiente]

Hola Víctor

Para medir la velocidad de conexión hice el siguiente programita:

CLEAR

oSQL.lTerminarConexion = .F.

T1 = TIME()

For I = 1 to 1000
  lcFila = "EXECUTE PROCEDURE GRABAR_VENDEDOR (0, 'ABC', '01-01-2011', 0)"
  llGrabacionOK = oSQL.Ejecutar(lcFila)
Next I

T2 = TIME()

? T1, T2

Return
*
*

Y el tiempo que tardó en ejecutarse fue de 5 segundos. Después lo volví a ejecutar, pero poniéndole el valor .T. a la propiedad lTerminarConexion y el tiempo fue de 29 segundos. Todo eso en mi propia computadora que es muy rápida y la conexión es local. Más tarde o mañana ejecutaré el mismo programa en una red LAN para anotar los tiempos. Lo que sí es indudable es que conectar-realizar la operación-desconectar es más lento (6 veces más lento en este ejemplo) que conectar-mantener la conexión abierta hasta el final del programa-desconectar.

En Windows la memoria caché es liberada cuando dejas de usar el programa que la reservó. Cuando te conectas a una Base de Datos, se reserva memoria caché, cuando te desconectas, esa memoria es liberada, no se queda ahí esperando por si vuelves a conectarte. Cada vez que te conectas y te desconetas esa secuencia se repite. Si estás en una LAN entonces el primero en conectarse ya hizo la reserva de la memoria caché pero esa memoria puede ir incrementándose a medida que más personas se van conectando. Y eso lleva tiempo, aunque sea mínimo a veces.

Con relación a cuando usar un tipo de conexión u otra creía que había sido suficientemente claro: en redes locales, en conexiones donde la seguridad no sea crítica y en accesos por Internet estables, usar conexión permanente. Pero cuando la seguridad es crítica (caso un cajero automático, por ejemplo o transferencia de dinero de una cuenta corriente a la otra) o cuando la conexión sufre constantes caídas, conectarse por demanda.

Por lo tanto, lo mejor es que tu aplicación le provea de ambas opciones al usuario (o al programador), como puedes ver en SQL_DEMO.

Saludos.

Walter.

---

Date: Mon, 9 May 2011 10:42:04 -0700
From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Javier Cabrera Blanco (Listas)]

>Y el tiempo que tardó en ejecutarse fue de 5 segundos. Después lo volví a ejecutar, pero poniéndole el valor .T. a la propiedad lTerminarConexion y el tiempo fue de 29 segundos. Todo eso en mi propia computadora que es muy >rápida y la conexión es local. Más tarde o mañana ejecutaré el mismo programa en una red LAN para anotar los tiempos. Lo que sí es indudable es que conectar-realizar la operación-desconectar es más lento (6 veces más lento >en este ejemplo) que conectar-mantener la conexión abierta hasta el final del programa-desconectar.

Esto es relativo Walter ....

 

El tiempo me dara la razon.

[IVAN MARTINEZ]

Victor tu disertacion teorica es correcta, pero tambien existe la realidad.

Y ya se expusieron las 2 alternativas.

Ya sabemos que se puede :

    1) Abrir la conexion y no cerrala sino hasta el final.

    2) Abrirla y cerrarla por cada Transaccion.

y

    3) En caso de que se caiga en cualquiera de los 2 casos anteriores hay que abrirla de nuevo.

 

El camino que se elija va a depender de las circunstancias y de la practica.

A Walter le ha ido bien dejando las conexiones abiertas

y no ha tenido queja de sus clientes,

ni ha tenido que comprar mas memoria,

ni se le han perdido los datos,

ni los hackers lo han invadido,

ni los clientes lo llaman para que reconecte la base,

entonces ???

 

Es bueno saber las alternativas

pero no se puede ser mas papista que el papa o que Walter.

 

Ivan Martinez

 

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Victor Espina
Enviado el: Lunes, 09 de Mayo de 2011 01:12 p.m.
Para: publice...@googlegroups.com
Asunto: Re: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Jose Antonio Blasco]

Ufff, Ivan mejor que no pongas en la misma frase a Walter y al papa. :-)))

Saludos.

--
Jose A. Blasco
Zaragoza - España

[Walter R. Ojeda Valiente]

Hola Iván

No, no he tenido quejas de mis clientes
No, no necesitaron comprar más memoria (ninguno tiene miles de usuarios conectados al mismo tiempo, cuando eso ocurra quizás necesitarán ampliarla)
No, no se perdieron datos, con Firebird una vez que realizas el COMMIT los datos quedan grabados permanentemente. Eso sí, se aconseja que las transacciones sean cortas porque todo lo que esté en la memoria se perderá si se corta la energía eléctrica.
No, hasta ahora al menos los hackers no causaron problemas. Y ninguna computadora está a salvo de ellos, si han entrado hasta el Pentágono y la NASA, imagínate si no podrán hacerlo en nuestras computadoras (siempre que tengan interés y tiempo libre, claro). Tener conexión permanente o por transacción no importa, si quieren entrar, entrarán. Como se conecte tu aplicación es lo de menos.
No, los clientes no me llaman para que reconecte la Base de Datos porque ésta se reconecta automáticamente si sufre una caída. Solucionando la causa de la caída se puede reconectarla sin problema. La técnica utilizada puedes ver en SQL_DEMO

Anteriormente ya explique las circunstancias en las cuales una u otra forma de conexión sería la más adecuada, quizás debería hacer un resumen y publicarlo para no estar repitiéndome a cada rato.

Saludos.

Walter.

---

From: iva...@gmail.com
To: publice...@googlegroups.com
Subject: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?
Date: Mon, 9 May 2011 23:31:47 -0430

[Victor Espina]

Creo que no me explique bien.  Cuando yo hablo de conexion por demanda no me refiero a abrir una conexion CADA VEZ que vas a enviar una sentencia al servidor y luego cerrarla.  Por ejemplo, supon un proceso donde estas grabando un pago de una factura pendiente. El proceso involucraria las siguientes actualizaciones:

1. Registrar el pago en caja o bancos

2. Registrar el pago en cuentas por cobrar

3. Actualizar el saldo del documento por cobrar

Tu prueba lo que hizo fue esto:

- Abro conexion

- Inserto registro en caja o bancos

- Cierro conexion

- Abro conexion

- Inserto registro en movimientos de cuentas por cobrar

- Cierro conexion

- Abro conexion

- Actualizo registro en cuentas por cobrar

- Cierro conexion

Esto  a todas luces es absolutamente impractico. Ahora entiendo cuando decias que tu rutina podia pasar de un modo a otro con solo activar una opcion. No.  A lo que yo me refiero con conexion por demanda es a abrir la conexion antes de INICIAR una serie de actualizaciones y cerrarla AL FINAL del proceso, no por cada instruccion enviada.  En el ejemplo anterior seria asi:

- Abro conexion

- Inicio transaccion

- Inserto registro en caja o bancos

- Inserto registro en movimientos de cuentas por cobrar

- Actualizo registro en cuentas por cobrar

- Cierro transaccion

- Cierro conexion

Como ves, en lugar de abrir tres veces la conexion la abri solo una vez y la cerre solo una vez. Por eso es que tu prueba da resultados irreales, y es por esto que yo decia que era dificil adaptar un sistema disenado a usar una conexion continua para que usara una conexion por demanda.

Saludos

Victor Espina

[Victor Espina]

 habia Sres, cada quien con su experiencia. La persona que origino este hilo hizo una pregunta y trate de responderla lo mejor posible SEGUN MI EXPERIENCIA. En ningun momento me he proclamado dueno de la verdad y mucho menos estoy en campana para que todo el mundo cambie su forma de programar y lo haga como yo lo hago, porque esa es la forma correcta y punto.  Hay un dicho muy bueno que dice "nadie aprende por cabeza ajena" y esto tambien aplica a la programacion. Cada quien evoluciona segun las necesidades y experiencias que se le van planteando.

En mi caso, yo tuve una experiencia fuerte con este tema que me llevo a ver las cosas como las veo ahora. Yo venia de trabajar con empresas cuyos sistemas eran usados por decenas de personas en redes locales, primero usando archivos DBF y luego con SQL Server, y habia usado la tecnica de conexion unica sin ningun problema ni con los usuarios ni con el servidor. 

Luego me contrato otra empresa para desarrollar un software ERP de grandes dimensiones, y mi equipo y yo pasamos casi tres anos disenando el sistema. Yo era el "arquitecto" de la cuestion y por tanto me toco disenar y programar la capa de acceso a los datos, y obviamente volvi a utilizar la tecnica de conexion unica.

Todo funciono bien con los primeros clientes, hasta que un dia nos llego la oportunidad de presentar e sistema a un posible comprador, el cual representaba el mejor negocio hasta la fecha economicamente hablando. Pero sin embargo, la venta se cayo. Porque? porque el cliente tenia varias sucursales en el extranjero y ellos querian que esos puntos se conectaran directamente con el servidor central (estamos hablando de una epoca donde aun no habia madurado la tecnologia de Terminal Server).  Aunque tecnicamente mi aplicacion podia conectarse con un servidor SQL Server remoto, en la practica no funciono pues la latencia de la conexion hacia que la misma se perdiera demasiado frecuentemente, cosa que no pasaba obviamente en las conexiones locales.

Debido a esa experiencia, me dedique a investigar y fue como di con varios articulos que explicaban el tema de las ventajas al usar un esquema de conexion por demanda.  Recientmente, me toco hacer un sistema en VFP9 con conexion a SQL Server y Sybase ASE, el cual seria utilizado a todo lo ancho y largo de Panama, contra un servidor central. Esta vez aplique el modelo de conexion por demanda y hasta la fecha no hemos tenido problema alguno debido a conexiones, ya que en el peor de los casos el usuario simplemente recibe un mensaje de error al pulsar el boton de ACEPTAR o ENVAR y puede intentarlo de nuevo sin problemas (tambien se aplico un diseno basado en storedProcedures para minimizar la cantidad de instruciones enviadas desde las estaciones al servidor).

Asi que como ven, mi experiencia me llevo a pensar de esta forma. La experiencia de Walter, tan valida como la mia, lo ha llevado a pensar que una conexion unica es la solucion mas practica para sus necesidades, y eso tambien esta bien.

Lo que no esta bien es que no podamos mantener una discusion "teorica" sobre los pros y contras de tal o cual metodologia, sin que la discusion empieze a caer en la linea de "a mi me funciona asi y punto". 

Eso no beneficia a nadie.  

Victor Espina

[Victor Espina]

Por cierto, lo olvdaba. Walter nunca ha tenido problemas con las capacidades de los servidores de datos de sus clientes. BIen por el. Pues resulta que yo si; no explicitamente causado por el tema de las conexiones, sino por bloqueos, pero el resultado fue el mismo: hasta que no me paso eso, nunca me preocupe por la carga que mi sistema le  pudiera poner al servidor de datos; ahora si.  Lo mismo pasara con Walter: hasta que no le toque lidiar con un servidor de datos colapsado por falta de recursos, no tendra razon para preocuparse por el tema del consumo de recursos causado por su aplicacion. y : quizas nunca le toque. :)

Saludos

Victor Espina

[Victor Espina]

Walter, en mi opinion, en un ambiente donde la seguridad de los datos que viajan por la conexion es una preocupacion, la forma de conectarte con la BD no implica ninguna diferecnia.

Si un hacker tiene puesto un sniffer a monitorear las conexiones de una estacion, le dara lo mismo si tu conexion esta abierta permanentemente y si la abres por demanda: igual podra ver lo que estas enviando por la conexion y capturarlo.

En estos casos lo que hace la diferencia son otras consideraciones, como enviar los datos encriptados, usar una VPN para encriptar la conexion, etc.

Victor Espina

[Victor Espina]

Amigo Walter, tiempo sin verte por estos lados!!! A ver si nos juntamos un dia de estos por Google Talk (ya no uso MSN) para ponernos al dia.

Bueno, respeto mucho tu opinion en cuanto a SQL Walter. Como comentaba mas abajo, yo si tuve problemas una vez de agotamiento de recursos en SQL Server, pero debido a un exceso de bloqueos. Sin embargo, dado que un lock. al igual que aun conexion, son elementos que basicamente consumen memoria, pues me parecio razonable el intentar mantener las conexiones abiertas al minimo posible, ademas de las otras razones que ya expuse.

Saludos

Victor Espina

Rancagua, Chile

[Victor Espina]

Tienes razon con tus cuentas, pero no olvides que las conexiones son solo UNA de las cosas que consumen memoria en un servidor. 

De todas formas estoy de acuerdo con lo que dices: actualmente la memoria RAM es tan barata que realmente ya no es un elemento ha considerar en el diseno de las aplicaciones, al menos en lo que respecto al servidor.

Victor

[Walter R. Ojeda Valiente]

Exactamente, es lo mismo que anteriormente había escrito yo.
 
Al hacker no le importa como tu aplicación, la mía o la de aquel otro se conecta a la Base de Datos.
 
Saludos.
 
Walter.
 

 

---

Date: Tue, 10 May 2011 04:54:30 -0700

From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Walter R. Ojeda Valiente]

Hola Víctor
 
No confundas, yo no he dicho que la conexión permanente a la Base de Datos sea la más adecuada siempre, lo que he dicho es que el tipo de conexión depende de las circunstancias, por ejemplo, en una red local la conexión permanente es mejor. También he dicho que lo correcto es poder cambiar de una forma de conexión a la otra muy facilmente y es así como está hecho en SQL_DEMO, donde solamente necesitas cambiar el valor de una propiedad de la clase SQL_Database para conectarte permanentemente o por demanda. Y como eso se hace por cada conexión entonces puedes tener a algunos usuarios conectándose en forma permanente y a otros por demanda en la misma Base de Datos y al mismo tiempo, obteniendo de esta manera "lo mejor de ambos mundos".
 
Parece que tendré que escribir un e-mail con los pros y los contras de cada forma de conexión para que se entienda mejor.
 
Saludos.
 
Walter.
 

 

---

Date: Tue, 10 May 2011 04:44:35 -0700
From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Walter R. Ojeda Valiente]

Hola Víctor
 
Pues yo no veo el problema, sería algo como:
 
1. Si no hay conexión con la Base de Datos
1.1. Conectarse a la Base de Datos
2. Iniciar transacción
3. Insertar registro en caja o bancos
4. Insertar registro en movimientos de cuentas por cobrar
5. Actualizar registro en cuentas por cobrar
6. Cerrar transacción
7. Si el valor de la propiedad lTerminarConexionConTransaccion = .T., entonces cerrar la conexión con la Base de Datos
 
Lo único que necesitarías sería crear una pequeña función que se encargue de los puntos 6. y 7. es decir: realizar el COMMIT y luego, según cual sea el valor de una (o más de una) propiedad cerrar la conexión o mantenerla abierta.
 
En otras palabras, no escribirías un COMMIT para cerrar una transacción sino que llamarías a una función que se encargaría de esa tarea y de mantener abierta o no la conexión.
 
Como ves, adaptar un sistema diseñado para conexión contínua a conexión por demanda es muy sencillo.
 
Saludos.
 
Walter.
 
 
 

---

Date: Tue, 10 May 2011 04:29:54 -0700
From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Miguel Antúnez]

Según yo haría lo siguiente

1.- conecto a la base de datos.

2. ejecuto SP de transacción. (dentro del SP esta todo lo que mencionan : begin transaction , insertar, actualizar, etc. commit o rollback)

3- cerrar conexión.

Saludos.

--
Miguel Angel Antúnez Camones
Especialista en SQL Server

mant...@frenosa.com.pe
mant...@gmail.com
miguel_...@msn.com
Cel. 997914428

Microsoft Active Professional
Membresía FY11-4D8A908D4C470

[Victor Espina]

En que forma es sencillo? acaso igual no tiene que ir a cada uno de los sitios donde se envian instrucciones a la BD a incluir la llamada a la nueva funcion que hace el COMMIT y el potencial cierre de conexion?

Es justo aqui donde radica la dificultado. Si mi sistema constan de unas pocas pantallas obviamente no sera nada del otro mundo. Pero intenta lo mismo con un sistema que tenga 100 pantallas y definitivamente no es algo que se logre en un par de dias.

Victor

[Victor Espina]

Totalmente de acuerdo. De hecho, ese es el esquema que he venido utilizando desde hace algunos anos. El unico inconveniente con ese esquema es que implica un poco mas de trabajo al programar y mantener los stored procedures.

Pero, en mi opinion, es una de las mejores formas de encarar un proyecto cliente/servidor, no solo con VFP sino con cualquier lenguaje.

Puedes buscar en Google por: SQL best sqlconnection strategy y veras que todos te diran dos cosas:

a) Si usas .NET y la funcion de connection pooling, da lo mismo si usas una conexion permanente o una conexion por demanda (no es el caso de VFP)

b) En CUALQUIER OTRO CASO, usa la conexion solo cuando la necesites y cierrala en cuanto termines de utilizarla.

Saludos

Victor Espina

[Miguel Antúnez]

para eso es bueno trabajar en capas. para no tener que hacer todo lo que mencionas.

una de las ventajas de trabajar en capas es eso: que solo modificando una capa pueda funcionar para todo.

y con una simple propiedad en tu objeto conexión puedes determinar si se conecta o desconecta por cada transacción e interacción a la base de datos

Saludos.

[Walter R. Ojeda Valiente]

Es que eso es cada vez más improbable. Las computadoras cada vez tienen más memoria, procesadores más veloces y discos duros más grandes y rápidos.
 
Y una de las tantas buenísimas cosas que tiene el Firebird es que su consumo de recursos es bajísimo. Como te dije en un e-mail anterior, puedo tener a 800 usuarios conectados simultáneamente usando solamente 100 Mb de RAM, u 8000 usuarios con 1 Gb de RAM, casi nada en esta época.
 
Saludos.
 
Walter.
 

 

---

Date: Tue, 10 May 2011 04:49:30 -0700

From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Miguel Antúnez]

Estoy en desacuerdo con la palabra mas trabajo, yo diría es mas disciplinado y mas trabajo en lo personal me costo al inicio, de ahí en adelante todos son beneficios. 

Saludos.

[Victor Espina]

Si, totalmente de acuerdo. De hecho, en principio estoy de acuerdo con Walter en que de esa forma tendrias lo mejor de ambos mundos.

Sin embargo no es algo tan facil de lograr como Walter lo ve. Si la aplicacion fue pensada desde un inicio en funcion de que todo acceso a los datos pasara por una capa especifica, entonces introducir cambios que afecten a toda la aplicacion es sencillo. 

Pero si la aplicacion no fue pensada de esa forma, y en lugar de usar una capa de acceso a los datos se utilizaron directamente las funciones SQLCONNECT() y SQLEXEC() cada vez que se necesitaron, entonces introducir cambios como este en toda la aplicacion es un trabajo enorme.

Incluso si se penso en una capa de datos pero no se pensio en el tema de las transacciones, introducir el manejo de transacciones una vez que el sistema esta listo tampoco es un trabajo facil.

Por eso es importante tomar estas decisiones al inicio del desarrollo y no al final.

Saludos

Victor Espina

[Walter R. Ojeda Valiente]

Hola Víctor
 
No tengo la menor idea de cual es el consumo de recursos de SQL Server porque nunca leí algo al respecto, mi experiencia se basa en MySQL (un poco) y en Firebird (muchísima), por lo tanto es de lo que puedo hablar con conocimiento de causa.

Saludos.
 
Walter.
 
 
 

---

Date: Tue, 10 May 2011 07:07:01 -0700
From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?

[Miguel Antúnez]

Exacto, el inicio marca el camino, al principio padecí de lo que comentas mis pantallas estaban llenas de sqlexec. así que opte por el rehacer mi software desde cero, obvio que esto es programación por que la idea de software era la misma. 

ahora que llevo varios años trabajando de esta forma, todo se me hace mas sencillo.

Saludos.

[Victor Espina]

Creo que le di reply al post que no era. El mensaje iba dirigido a tu tocayo Walter Valle, el cual conozco desde hacer muchos anos y que me ha ayudado muchisimo en temas de SQL Server.

Saludos

Victor

[Walter R. Ojeda Valiente]

Hola Víctor
 
Pues sigo sin ver la dificultad, el único problema sería el tiempo que tardarías en reemplazar el texto si es que tienes un montón de formularios sueltos con sus respectivos COMMIT pero si tienes clases de formularios entonces harías los reemplazos en pocos segundos.

 Lo único que tendrías que hacer es buscar cada instrucción COMMIT y reemplazarla por la nueva función, por ejemplo: GrabarTransaccion()
 
Aunque tengas que hacer 300 reemplazos eso no te tomará más de un día y si obtendrás buen dinero entonces se justifica ampliamente el tiempo empleado.
 
Saludos.
 
Walter.
 
 
 

---

Date: Tue, 10 May 2011 11:01:08 -0700

From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Walter R. Ojeda Valiente]

Hola Víctor
 
Pues entonces allí está la diferencia. Es que yo sí desde el principio pensé en eso, en el tema de las conexiones y las transacciones.
 
Como ya lo dije varias veces, lo más importante para desarrollar una buena aplicación es tener muy claras las ideas antes de escribir la primera línea de código fuente. Lo demás viene solo.
 
Saludos.
 
Walter.
 

 

---

Date: Tue, 10 May 2011 11:11:38 -0700

From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Victor Espina]

100% de acuerdo. Lamentablemente este tipo de pensamiento rara vez se logra en los primeros anos como programador. Los programadores novatos tienden a ir programando sobre la marcha e ir resolviendo como pueden a medidan que van avanzando.

Tambien te asombrarias de la cantidad de programadores que no estan claros con OOP y su implementacion.

Asi que es un aprendizaje y solo despues de mucho tiempo es que se llega al punto en el que entiendes lo vital de la programacion por capas y de la abstraccion.

Saludos

Victor Espina

[Walter R. Ojeda Valiente]

La verdad verdadera es que me extrañó tanta amabilidad y sospeché algo así.

:-)

Saludos.

Walter.

---

Date: Tue, 10 May 2011 11:31:32 -0700

From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?

[Walter R. Ojeda Valiente]

Hola Víctor

Es cierto, a mí debo reconocer que lo que me ayudo mucho es la lectura de libros, siempre me gustó leer y cuando empecé a programar leí un montón de libros de Informática porque tenía sed de aprendizaje.

Supongo que gracias a eso ahorré mucho tiempo, lo que a otros les toma años de tropezones a mí me tomó meses.

Saludos.

Walter.

---

Date: Tue, 10 May 2011 13:33:05 -0700

From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] [VFP] Conexion Permamnte o NO a MySQL?

[Victor Espina]

Ja ja. No vale, a pesar de nuestras ocasionales diferencias, creo que siempre he sido amable y respetuoso contigo Walter. Di mas bien que te extrano el exceso de familiaridad, porque como te decia a Walter Valle lo conozco desde hace muchos anos y ya ves que tampoco es que siempre hemos estado de acuerdo. :)

Saludos

Victor Espina

[Walter R. Ojeda Valiente]

Hola Víctor

Sí, por supuesto, siempre has sido amable conmigo y creo que yo siempre he sido amable contigo también. Pero ante tanto exceso de amabilidad solamente podía suponer que te habías equivocado de destinatario, más aún considerando que yo escribo casi todos los días en el grupo y según tu e-mail hacía mucho que no leías los comentarios de Walter.

Saludos.

Walter.

---

Date: Wed, 11 May 2011 04:52:42 -0700

From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: Re: RE: [vfp] Re: [VFP] Conexion Permamnte o NO a MySQL?

[Easy Gestion]

gracias