Consideraciones al trabajar en red

[Juan Pablo]

Foxeros:

Hasta ahora mis programas han sido bastante sencillos y funcionales
para 1 sola máquina, sin embargo estoy requiriendo migrar una
aplicación de forma que se trabaje en varias máquinas al mismo tiempo
y se retenga todo en una sola base de datos. Es decir que desde la PC1
y PC2 se pueda ingresar información de forma que todo se ingrese en
una sola base de datos, sin que entre ellas se generen conflictos.

Aquí mis dudas:

1 .Como hago para que ambas máquinas puedan usar las mismas tablas, o
es mejor que cada máquina use su propia tabla y luego se unan

2. Cuando se abre un código, como hago para que no se pueda volver a
abrir en la otra máquina por error?

3. Algún ejemplo sencillo que tengan me ayudaría, en fin cualquier
información que me permita evitar errores que ustedes por su
experiencia sin duda ya saben como evitar.

Saludos,

[Amaro Silva]

Sin lugar a dudas que la mejor opción es migrar tu aplicación a un motor de base de datos (sql server, mysql,etc), pero esto te puede llevar un buen tiempo.
Si haces uso de dbf revisa la ayuda del comando USE para uso exclusivo y uso compartido.

Podes colocar las tablas en un recurso compartido de la red, pero vas a tener que controlar los accesos en simultaneo.




--
Amaro Silva.

[ERNESTO GUZMAN]

Realmente es muy sencillo, yo tengo aplicaciones en red y no tengo problema alguno y lo mejor es que no tengo que cambiar codigos ni nada..

Imagino que tienes la ayuda de visual fox.. en ella viene un apartado que es programar para acceso compartido..

yo utilize las sesiones privadas de datos que hacen perfectamente lo que tu quieres y sin tanto rollo de codigo solo unos cuantos pasos y no necesitas cambiar formularios ni nada.

--
Ernesto G.

[Luis Mata]

Pero que es lo que quieres hacer? migrar a un motor de Base de datos, Sql,
Mysql, Postgres.
Especifica que es lo que quieres hacer.

2. Cuando se abre un c�digo, como hago para que no se pueda volver a
abrir en la otra m�quina por error?

Esto no lo entiendo. Contradice lo que quieres hacer, un dato puede y debe
de ser modificado si es posible en 2 terminales uno despues del otro, esto
por tema de seguridad.

Luis

----- Original Message -----
From: "Juan Pablo" <jpsando...@gmail.com>
To: "Comunidad de Visual Foxpro en Espa�ol"
<publice...@googlegroups.com>
Sent: Tuesday, July 27, 2010 9:48 AM
Subject: [vfp] Consideraciones al trabajar en red

Foxeros:

Hasta ahora mis programas han sido bastante sencillos y funcionales

para 1 sola m�quina, sin embargo estoy requiriendo migrar una
aplicaci�n de forma que se trabaje en varias m�quinas al mismo tiempo

y se retenga todo en una sola base de datos. Es decir que desde la PC1

y PC2 se pueda ingresar informaci�n de forma que todo se ingrese en

una sola base de datos, sin que entre ellas se generen conflictos.

Aqu� mis dudas:

1 .Como hago para que ambas m�quinas puedan usar las mismas tablas, o
es mejor que cada m�quina use su propia tabla y luego se unan

2. Cuando se abre un c�digo, como hago para que no se pueda volver a
abrir en la otra m�quina por error?

3. Alg�n ejemplo sencillo que tengan me ayudar�a, en fin cualquier
informaci�n que me permita evitar errores que ustedes por su

[Walter R. Ojeda Valiente]

Hola Juan Pablo

PRIMERO. Debes decidir si usarás las tablas nativas del VFP (las .DBF) o si usarás un motor de Bases de Datos SQL (MySQL, PostgreSQL, Firebird SQL, etc.).
         Ambas opciones tienen sus ventajas y sus desventajas, no hay nada perfecto. Si normalmente usas .DBF, los cambios a realizar son menores pero 
         también la seguridad es menor. Pasarte a un SQL requiere mucho tiempo, no lo harás en un día ni en dos, eso ni lo sueñes. Pero en contrapartida 
         tus aplicaciones serán mucho más robustas, seguras y confiables.

SEGUNDO. En tus formularios te conviene ponerles la opción: Data session "2 - Private Data Session", así cada formulario manejará sus propios datos y no
         interferirá con los datos de otros formularios.

TERCERO. Si te decantas por los .DBF, debes abrir las tablas en forma compartida (SHARED), para que los otros usuarios de las red puedan acceder a ellas

CUARTO. Las tablas deberían estar en una sola carpeta, en el servidor, y todos los usuarios acceder a ellas cuando las necesiten. Eso de estar uniendo 
        tablas es causante de problemas, más lento, y la información no está siempre disponible para todos.

QUINTO. La ventaja de las aplicaciones multi-usuario es que muchos usuarios pueden estar consultando o agregando datos a las mismas tablas al mismo 
        tiempo, pero en este último caso debes evitar las colisiones. ¿Cómo? eso dependerá del aprovechamiento que utilices (.DBF libres, Bases de Datos 
        Visual FoxPro, SQL, etc.)

SEXTO. Para asegurarte que todo funciona bien te conviene hacer pruebas en 2 ó 3 computadoras al mismo tiempo. Deberías hacer un programa que corra 
       en red y que su función sea agregar datos a la misma tabla. Por ejemplo, que le agregue 1.000.000 de registros a la tabla CLIENTES. Si lo corres 
       en 3 computadoras, cuando los 3 terminen deberías tener 3.000.000 de registros y ningún código duplicado. Si no es así, debes buscar y corregir 
       los errores.

Saludos.

Walter.

---

Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.

[william zuluaga]

hola.

 

yo trabajo desde hace tiempo con lo que necesitas, lo unico que tienes que hacer es abrir las tablas o bases de datos en forma no exclusiva.

 

para tener aceeso a una pc como servidor, es mas facil si compartes una carpeta en la red y luego de las otras pc te conectas por medio de una unidad de red, asi te sera mas sencillo direccionar los reportes y archivos que necesites.

 

para borrar fisicamente cualquier registro de la tabla, la debes abrir en forma exclusiva y en ese proceso ninguna otra maquina puede acceder a las tablas, debes controlar este tipo de proceso.

 

espero te sea de ayuda

 

william zuluaga

---

De: Juan Pablo <jpsando...@gmail.com>
Para: Comunidad de Visual Foxpro en Español <publice...@googlegroups.com>
Enviado: mar,27 julio, 2010 09:48
Asunto: [vfp] Consideraciones al trabajar en red

[Jorge Montúfar]

buenas noches y saludos cordiales

yo hago direcciono el servidor y creo un exe solo para las terminales,
es algo como este codigo:

********* para terminal quitar asteriscos y poner asteriscos en la
parte del servidor
*SET DEFA TO \\server\Copiasuro\data
*SET PATH TO \\server\Copiasuro\TABLAS;\Copiasuro\DATA;\Copiasuro\PROYECTO;\Copiasuro\MENU;\Copiasuro\FORMAS;\Copiasuro\CODIGO;\Copiasuro\ICONO;\SICOFIN\INFORMES;\SICOFIN\QUERY;\SICOFIN\CLASES;\SICOFIN\CONTA\screen;\SICOFIN\CONTA\reportes;\SICOFIN\CONTA\programa;\Copiasuro\CONTA\bmps;\Copiasuro\CONTA\dbf00
*****************************

****** para el servidor quitar asteriscos y poner asteriscos en la
parte de la terminal
SET DEFA TO c:\Copiasuro\data
SET PATH TO c:\Copiasuro\TABLAS;\Copiasuro\DATA;\Copiasuro\PROYECTO;\Copiasuro\MENU;\Copiasuro\FORMAS;\Copiasuro\CODIGO;\Copiasuro\ICONO;\copiasuro\INFORMES;\copiasuro\QUERY;\copiasuro\CLASES;\copiasuro\CONTA\screen;\copiasuro\CONTA\reportes;\copiasuro\CONTA\programa;\Copiasuro\CONTA\bmps;\Copiasuro\CONTA\dbf00
****************

SET EXCL OFF
SET ESCAPE OFF
SET CLOCK STAT
SET CLEA ON
SET BRST OFF
SET CONS OFF
SET DELETED on
SET MESS TO
set mult on
SET DEBUG OFF
CLEA
CLOSE DATA
*#INCLUDE comun.h
public v_empresa
v_empresa = 'COPIASURO, R.L.'
_screen.height = 560
_screen.width = 847
_screen.autoCenter = .T.
_screen.caption = 'SISTEMA INTEGRADO CONTABLE & FINANCIERO '
_screen.icon = '\Copiasuro\ICONO\SICOFIN.ICO'
_screen.picture = '\Copiasuro\ICONO\SICOFIN.bmp'

DECLARE INTEGER FindWindow IN Win32API STRING lpClassName, STRING lpWindowName
DECLARE INTEGER BringWindowToTop IN Win32API INTEGER hwnd
DECLARE INTEGER SendMessage IN Win32API INTEGER hwnd, INTEGER Msg,
INTEGER WParam, INTEGER LParam

IF LAST() = 27
CLEA ALL
CLOS ALL
RETU
ELSE
DO FORM LOGIN
READ EVENT
ENDI
SET CLOC OFF
CLEA ALL
CLOS ALL
SET SYSMENU ON
CLEA ALL
CLOS ALL

gracias a todos los foxeros por las respuestas que les dan a los demas
yo leo y aprendo.

jorge desde Guatemala

El 12/08/10, william zuluaga <w2k2s...@yahoo.es> escribió:

[IVAN MARTINEZ]

Disculpa William

 

com respecto a eso de borrar la fila fisicamente si estas con base de datos vfp no es aconsejable,

por el tiempo que lleva la reorganizacion de la tabla.

 

Siempre he trabajado foxpro sin borrar fisicamente el registro con delete que marcar el registro como borrado.

 

Y teniendo en cuenta que siempre hay que tener <set deleted on> para no tomar en cuenta para nada los registros eliminado.

 

Ivan Martinez 

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de william zuluaga
Enviado el: Jueves, 12 de Agosto de 2010 08:11 p.m.
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Consideraciones al trabajar en red

[Walter R. Ojeda Valiente]

Hola Ivan

Yo lo que hago es empaquetar las tablas (PACK) en el momento que el usuario sale de la aplicación. Le muestro una barra de progreso y el nombre de cada tabla que está siendo empaquetada. De esa manera, cuando vuelve a ingresar a la aplicación, ninguna tabla tiene registros marcados para ser borrados.

Desde luego, el empaquetamiento lo realizo si nadie más está usando esa tabla.

Saludos.

Walter.

---

From: iva...@gmail.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Consideraciones al trabajar en red
Date: Sun, 15 Aug 2010 23:41:21 -0430

[william zuluaga]

hola,

 

me parece perfecto lo que te sugiere walter, en algun momento es necesario eliminar los registros marcados para borrar, pues esto le va generando espacio innecesario el la tabla, si tiene problema con la indexacion, ejecute el comando reindex.

 

yo en particular, para las tabla principales elaboré una papelera de reciclaje, por si algun dia necesitan recuperar dichos archivos, o porque en mi medio es comun la desconfianza de los usuarios y siempre les echan la culpa al programa cuando eliminan un registro que no debia, con esto les demuestro al usuario el dia y la hora de la eliminacion.

---

De: Walter R. Ojeda Valiente <wr...@hotmail.com>
Para: publice...@googlegroups.com
Enviado: lun,16 agosto, 2010 08:29
Asunto: RE: [vfp] Consideraciones al trabajar en red

[IVAN MARTINEZ]

Asi, si

 

Saludos

Ivan

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Walter R. Ojeda Valiente
Enviado el: Lunes, 16 de Agosto de 2010 09:00 a.m.
Para: publice...@googlegroups.com
Asunto: RE: [vfp] Consideraciones al trabajar en red

[IVAN MARTINEZ]

A mi me gusta dejar un buen rato los registros eliminados, sirven de auditoria.

 

Ivan

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de william zuluaga

Enviado el: Lunes, 16 de Agosto de 2010 09:27 a.m.

[Ricardo Pina]

Una buena práctica es tener una tabla con los comprobantes borrados incluyendo usuario, terminal y fecha de borrado.

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

[IVAN MARTINEZ]

Es correcto Ricardo, eso lo hago en una dbf de auditoria, pero mantengo tambien sin ningun esfuerzo toda la info borrada.

 

Ivan

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Ricardo Pina
Enviado el: Lunes, 16 de Agosto de 2010 11:03 a.m.

[Luis Mata]

Yo para evitar esto estoy implementando una politica de no ANULACION DE DATOS, en cuanto a lo documentario.

 

Facturacion , se controla con los documentos en mi caso no se anula una factura sino se hace un Nota de credito.

Almacen , Ingreso de articulos si hay un error no se anula se utiliza un documento que se llama extorno.

Y asi estoy evaluando las incidencia y tratando de quitar el tema de anulaciones.

 

Luis

[IVAN MARTINEZ]

Eso es lo mejor, eliminar nada o  en lo posible.

En general nunca elimino registros ya creados.

Lo que sucede es que algunas aplicaciones se crearon con el esquema de que

 

- segun el status los registros se encuentran en diferentes archivos.

- pendiente

- pagado

- anulado

 

entonces hay que eliminar de uno y pasarlo a otro.

 

Pero como tu bien dices la eliminacion como regla no debe existir, sino las operaciones de reverso o manejo de status.

Y lo viejito va pasando a historicos.

 

 

Ivan

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Luis Mata
Enviado el: Lunes, 16 de Agosto de 2010 07:58 a.m.

[william zuluaga]

pero en algunos casos si se hace necesario el poder eliminar registros, en mi caso que tengo una aplicacion que maneja hojas de vida de diferentes tipos, es necesario.

 

william zuluaga

---

De: IVAN MARTINEZ <iva...@gmail.com>
Para: publice...@googlegroups.com
Enviado: lun,16 agosto, 2010 12:27