Como Evitar que los Indices CDX se dañen cuando hay perdida de corriente electrica y pierda conexion de Red

[Nelson Rios Pinedo]

Hola amigos de la comunidad Fox:

Uno de los principales problemas que tenemos en VisualFoxpro es que las tablas y los indices se malogran muy a menudo

cuando se va la luz y nos lleva tiempo para arreglar las tablas e indices. Existe alguna herramienta para evitar este problema??

Cordiales Saludos amigos y gracias por sus sugerencias.

[Douglas Sánchez]

En esperiencia cuando trabaje con dbf te digo que aprendi dos cosas,

1 Que en el metodo del formulario LOAD, ahi abro las tablas mando a cargar archivos temporales cursores para mostrar informacion en grid, combos, textbox etc.
2 y hago los siguiente despues de usar cada tabla, pocas veces dejo abiertas las tablas en un entorno Red, Lo otro es en teoria usar vistas locales, o remotas y asi evitas que se corrompan tus tablas.

select tabla1

use

cierro esas tablas asi sucesivamente

3 En tu menu inclui una area de mantenimientos, de borrado de indices y vuelver a crearlos. ejemplo

use tabla exclu

delete tag all

pack

index on codigo tag codigo

index on idpartes tag idpartes

Este ejemplo lo corres mientras hay problmas de indices y listo.

Saludes

Douglas

[Víctor Hugo Espínola Domínguez]

Hola Nelson

>Existe alguna herramienta para evitar este problema??

Sí existe, se llama UPS ;-)

Saludos,

Víctor.

[Edgar Acevedo]

1- Los índices NO SE DAÑAN si se corta la corriente con las tablas simplemente abiertas o en modo de consulta.

2- Los índices solo se dañan (A VECES) cuando el "apagón" sucede mientras se están grabando datos.

Si tu caso es el No. 2 indicado arriba, NO HAY FORMA DE EVITARLO porque sencillamente la computadora trabaja con electricidad, no con magia, y si el apagón sucede mientras se estaban grabando datos y estos solo alcanzaron a ser enviados en un 80%, ¿De donde se va a sacar, cualquier herramienta o truco del mundo, ese 20% de datos que no alcanzó a ser transmitido?

Para "suavizar" un poco la posibilidad de daño en las tablas es que se inventaron las TRANSACCIONES (Begin y Commit).  En el caso de VFP9, existe el concepto de "Buffering" cuya idea es evitar la corrupción de tablas e índices mediante "el truco" de evitar que los encabezados se vean alterados solo hasta que las transacciones se hayan cometido.  Pero aún así, a veces "popopasa" (shit happends) y mas de alguna tabla o índice se corrompe. 

Para evitar este problema es que muchos programadores optan por usar el modelo Cliente-Servidor, donde el control de las TRANSACCIONES (mencionadas en el párrafo anterior) suceden a nivel del servidor y por lo tanto no suceden las corrupciones de datos tan facilmente como con las tablas nativas de VFP).

Y como te ha dicho genialmente Victor Hugo: la herramienta utilizada para evitar las corrupciones de datos ya existe desde hace muchisimos años (casi que nació de la mano con la informática) y se llama UPS. 

Si a tu cliente no le gusta, pues dile que le ofrecerás una solución cuando él encuentre la forma de que una bicicleta no caiga de lado al perder su "momentum".  O cuando el encuentre un avión capaz de volar aún cuando haya perdido sus alas, o un corazón humano pueda seguir latiendo aún cuando no reciba señales eléctricas.  Hay clientes y usuarios tercos a los que hay que hacerles este tipo de comparaciones idiotas para que finalmente entiendan que TODO equipo informático NO ESTA COMPLETO sin un UPS.  El UPS no es un accesorio, es UNA PARTE VITAL de todo el equipo informático.  Si no tiene dinero (o lo mas seguro: NO QUIERE gastar en UPS), entonces que en lugar de monitor compre un UPS.  No tendrá corrupción de datos, pero tampoco podrá ver nada ¿Por qué? porque tan importante y vital es el monitor como lo es el UPS.  Repitele claro: el UPS (y uno bueno) es parte básica del equipo, no es una "opción".

Salu2,


Edgar Acevedo

 

[Fidel Charny]

También resulta necesario recordar que además de las PC, deben incluir en UPS a los switcher. Generalmente los dejan afuera.

[Fernando D. Bozzo]

Hola Nelson:

Te comento algunas opciones que tenés y que seguramente algunas ya te las hayan puesto los demás compañeros:

* El mecanismo más seguro para evitar problemas con las tablas es mantenerlas cerradas todo el tiempo, excepto en los momentos puntuales en los que serequiera hacer una consulta o una actualización, en cuyo caso la tabla se abre/actualiza/cierra. El problema que podés tener con esto es si usás las tablas de la forma tradicional (antigua) donde están todo el tiempo abiertas. Yo uso el mecanismo que te comento y la corrupción de tablas bajó estrepitosamente.

* Otra forma es usando un acceso cliente/servidor por medio de RPC o por web-services, de esa forma solo el servidor (con UPS) es el único que maneja y accede las tablas directamente, y los PC clientes simplemente hacen sus peticiones al servidor, nunca tocan las tablas. Si se cuelgan los PC clientes no pasa nada porque no tocan los datos directamente y de paso te avitás tener que comprar unas cuantas UPSs.

* Lo de las transacciones, aunque Fox las tiene, no son muy fiables ni evitan la corrupción de los datos. Están pensadas más que nada para actualizaciones atómicas, o sea, actualizar todo o nada y evitar problemas de integridad referencial. Además en una red con muchos usuarios, las transacciones enlentecen bastante las actualizaciones y provocan bloqueos en la red.

El mejor consejo que puedo darte es que empieces a pensar en un modelo cliente/servidor, te olvides de los típicos grid que muestran toda la tabla entera y comiences a mostrar grid con consultas controladas y filtradas que pidan los datos al servidor en grupos de registros. Además de esta forma tu BDD no tiene porqué ser los DBFs, sino que al ser un acceso cliente/servidor la BDD puede ser cualquier otra (MariaDB, MySQL, etc)

El único problema es que esto puede implicar que rediseñes una buena parte de tu aplicación.


Saludos.-

[Luis Maria Guayan]

UPS (Sistema de energía ininterrumpida)

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Murray1971]

En realidad, todas la opciones q te han dado son las valederas y creo q la que existen.

En lo particular te digo q donde vivo, Oberá Misiones Argentina los cortes de luz son frecuentes y tengo una sistema
hecho en MS-DOS q se corrompía SIEMPRE, solución q encontré una vez ha hacía las actualizaciones en las tablas, dichas tablas
actualizadas las cerraba y las volvía a abrir y con ello se solucionó el problema.

Saludos. Fabián.

[Daniel Marte]

Mi solucion fue la siguiente

a) no uses indices compuestos, porque estos son los que se dañan

b) como son necesarios estos indices, creas un campo con el tamaño de los campos que quieres unir y en este campo guardas la informacion de los campos deseados y creas un indice con este campo, como es un indice simple no da problemas, pero la informacion que contiene es compuesta.  En caso de cortes de energia electrica, nunca tendras problemas.

c) por ejemplo, si tienes un indice con campo codigo y fecha, creas un campo del tamaño de los dos y guardas aqui estas informaciones.

d) cuando indexes este campo, va a traer la informacion de los campos que has unido y listo, no da problemas aun con fallo de energia electrica.

Saludos

[Carlos Miguel FARIAS]

Es la primera vez en >20 años con fox que leo que un índice compuesto es mas factible (o los únicos) que se rompen con un corte de luz.
Cuando se corta la luz, no hay gimonte que valga. En todo proceso de datos hay parte que en algún momento esta en memoria cache y cuando se corta el fluido eléctrico, se borran, sea dbf u Oracle.
Pasa que en los motores SGBD hay una bitácora (log) que hace una pre escritura de cada transacción. Si al medio se corta por cualquier falla, al arrancar el SGBD automáticamente restaura la situación eliminando todo aquello incompleto y completando lo que puede armar desde el log.
Fox. Como trabaja sin un motor centralizado (con tablas dbf) no puede hacer eso.
En mi caso instrumento un control de tabla abierta/cerrada y si al arrancar, detecta que la tabla no fue cerrada, como mínimo reindexa.
Saludos: Miguel, La Pampa (RA)

[Fer]

Totalmente de acuerdo con Miguel, da igual si el índice es compuesto, compacto o todo lo contrario.

[Ricardo Pina]

Tal vez omitió en su explicación que el día que terminó de reconstruir todos sus indices, el jefe cansado de los cortes de luz instaló un UPS.

uff, ya estoy añorando el viernes.

 

Saludos

--

            

                   Ricardo Pina

Desarrollo y Servicios Informáticos

                  Profesionales
               www.dsip.com.ar

 

 

[Guillermo MDQ]

Simplemete hazle una pregunta a tu jefe:

Que vale mas para ti, una UPS o la informacion que tienes guardada en los archivos ?

Si la respuesta es la primera opcion, entonces no te hagas mas problema y sigue como hasta ahora.

Saludos
Guillermo

[mapner]

La respuesta a la inestabilidad de DBFs y CDXs es... en lo posible pasar a Cliente / Servidor. Buscar algún buen motor ya sea gratis o de pago (si aún usan DBFs es por que lo gratis les irá bien).

Cuanto antes huyas de DBF/CDXs un problema menos en tu vida... Si bien el cambio lleva algo de trabajo no es imposible y las ventajas son muchísimas.

Recomiendo Firebird. 

saludos

[Carlos Miguel FARIAS]

La UPS se instaló casi desde el primer día, pero a veces, ciertos drivers de impresión colgaban el S.O. muy seguido.

Una aplicación bien normalizada, con los indices apropiados, se reindexa relativamete rápido.

En algunos procesos largos, puede venir el de la limpieza, pegar un tiron, desconectarte el cable de energia.

Es cierto lo del SGBD, pero en entornos chicos,a veces no amerita montar un SGBD.

Tengo un sistema que maneja posiblemente mas de un giga de datos, pero son imagenes almacenadas en disco (no en las tablas), montar un SGBD para 200 kbytes de dbf, es me parece, matar polillas con una calibre .50

Saludos: Miguel, La Pampa (RA)

[mapner]

Miguel,

Sobre si vale la pena instalar un SGDB, es posible que por 200kb no convenga ORACLE u MS-SQL u otro de los "pesados" donde una instalación lleva tiempo y recursos. Por eso una muy buena opción es Firebird. El instalador pesa 13MB, el servicio del motor se instala en 30 segundos y listo para usar. FB se puede utilizar para BDs de 200k como para BDs de varios GBs sin problema. El tema no es el tamaño de los datos sino la estabilidad y la seguridad. A su vez, si son 200k pero los datos son críticos y de alta disponibilidad el problema es el mismo. Las DBFs cumplieron una loable función cuando no había otras opciones o las alternativas eran caras y de difícil acceso. Hoy el panorama ha cambiado. La única opción que parece justificable para seguir usando DBFs es tener que mantener sistemas legacy donde es caro o no conveniente su reconversión, a riesgo de inestabilidad de datos.

saludos

[Carlos Miguel FARIAS]

Totalmente de acuerdo.
Al nivel y las opciones que da firebird, es un SGBD que se debe tener en cuenta siempre.
Nosotros en el trabajo le estamos apunta a postgresql, porque soporta datos geoespaciales.
Pero en realidad, para el tamaño de las base se que estamos usando, cualquiera de los dos segual (diría Minguito)

Saludos: Miguel, La Pampa (RA)

[Fer]

Ja,  Minguito!  Qué recuerdos Miguel!  :-)

[Carlos Miguel FARIAS]

Al momento del diseño de la aplicación, para prototipado de la interfaz del usuario y pruebas preliminares, no descarto el uso de las dbf.

Lo importante es que todo el acceso a datos fisicos se haga usando sentencias SQL o cursores adapter, y solo usar los comandos específicos de fox para trabajar con los cursores resultantes (sobre todo de un select).

De esa manera, mientras se está protipando, no me tengo que estar preocupando si el servidor está levantado o si tengo conexión, o estoy en el lugar sagrado con la notebook (esto último y siendo viernes es una buena estrategia para que no te la pidan prestada).

Una vez que tengo desarrolladas las capas visual y de negocios, convertir el SQL a SPT y los cursores adapters apuntarlo de nativas a el sgbd propiamente dicho, ya es algo relativamente menor.

En general el SQL de VFP 9 es un 95% compatible con cualquier SQL, y por supuesto, ciertas funciones especificas del SGBD que se seleccione, se deberán instrumentar cuando estes ya conectado.

En python por ejemplo, para prototipear uso sqlite, muy interesante pero con muy baja concurrencia y como la interfaz DB API es casi identica para casi todos los SGBD, casi lo único que tengo que tocar es la sentencia de conexión.

Saludos: Miguel, La Pampa (RA)

[Ricardo Pina]

Hola Carlos

 

Para complemetar tu comentario, solo un detalle a mejorar, al lugar sagrado es mucho mejor llevar lapiz y papel que siguiendo los standares es reutilizable.

 

Saludos de Viernes

[Luis suescún]

Una UPS, es la solucion para que haya la posibilidad de cerrar a tiempo el sistema.

Si no hay UPS, yo creo que es posible controlar el daño de los tablas y/o indices.

Trabajando con ODC o con cursoradapter, la clase de datos, con estos 2 metodos, nunca se abren las tablas directamente.

Me ayudan, con cualquier otra inquietud

2013/6/22 Nelson Rios Pinedo <nelson...@gmail.com>

[Jose Padron]

Mi opcion es simple.... no uso ningun tipo de indice....    siempre hago consultas sql into cursor temporal

no fino

nunca me falla

El sábado, 22 de junio de 2013 00:45:45 UTC-4:30, Nelson Rios Pinedo escribió:

[Enrique Martinez]

la herramienta que no falla y es de muchos comentada aqui en el foro es el no break

Saludos

Enrique Martinez

[Daniel Sánchez]

Lo mejor es usar un ups que permita si no vuelve la energía eléctrica realizar el apagado de la pc de manera automática.

Saludos

[Analyzer]

Muy bien explicado..

Me pregunto si aun en el modelo Cliente-Servidor, el servidor tendría que usar un UPS?... Am.. Creo que no... jejeje.. (Por favor entiéndase el sarcasmo).

Saludos!

[Fernando D. Bozzo]

Hola Edgar:

Sobre tu aseveración Nº1: Estás equivocado.
Te puedo asegurar que cuando se hace trabajo concurrente en red contra un servidor, FoxPro cachea datos que ante ciertos problemas de red o de cuelgue de un cliente pueden provocar la corrupción no solo de los índices sino también de las tablas. Uno de los problemas más graves y que más afectan a las tablas en red es la latencia de la red, y como la actualización de las tablas depende de que funcione perfectamente la actualización que le hacen los clientes, siendo que cada cliente escribe directamente en la tabla, a diferencia de una arquitectura cliente/servidor, esto hace que cualquier problema mínimo de cualquiera de los clientes (latencia, microcortes, problema de placa de red, virus, sistema de archivos sobre-exigido, etc) pueda joder los datos y sus índices.
Ya hay mucho escrito sobre esto desde hace muchos años (fox.wikis.com, Universal Thread, etc) y una UPS no soluciona el problema, solo puede minimizarlo un poco en aquellos sitios donde los cortes de luz sean habituales, pero nada más.


Saludos.-

[Fernando D. Bozzo]

Debe ser contagioso: Aquí estoy contestando algo de hace 2 meses....

[almonts ( www.ontarioxb.es )]

Una opción muy sencilla de implementar es utilizar el comando FLUSH.
No es la solución, pero te ayudará bastante.
Después de un APPEND, REPLACE, DELETE, INSERT, UPDATE.
Sobre todo si modificas campos de la tabla que además son indices.

Es posible una ligera pérdida de rendimiento pero será inapreciable

Leete la ayuda de FLUSH