Como prever indices corruptos..

[Fox Learner]

Me preocupa el comentario de Jairo sobre que un cliente intentó aprovecharse de su nobleza justificando que "el sistema no era confiable" ya que según menciona Jairo, probablemente el índice fallo al momento de calcular cantidades relativas a la facturación.

Hay alguna forma de "anticiparse" y determinar si los archivos de índice están corruptos, antes de correr procesos en especial de cálculos?...

Hablo de un escenario para trabajo en red (porque si fuera monousuario, pues solo regeneraríamos los índices antes de cada cálculo, un indicador de progreso y listo..)

Gracias anticipadas!

[Walter R. Ojeda Valiente]

No hay un comando o función que te indique si un índice está ok o está corrupto.

Pero puedes descubrirlo utilizando la construcción TRY...CATCH...ENDTRY cada vez que abres una tabla.

Para facilitarte la vida y tener una lógica más clara, en lugar de escribir:

USE MiTabla

escribirías algo como:

DO AbrirTabla with "MiTabla", "MiIndice"

y en la rutina AbrirTabla abres la tabla y su índice asociado y en caso de alguno de ellos estar dañado, corriges el problema.

Saludos.

Walter.

P.D.: De todas maneras, usar tablas .DBF es obsoleto, usando un SGBD tal como Firebird, Mysql, Postgre, etc., no tendrás esa clase de problemas.

---

Date: Fri, 17 Aug 2012 10:26:32 -0700
From: thenewin...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Como prever indices corruptos..

--
 
 
 

[gonzal...@hotmail.com]

Amigo Fox learner gracias por la aclaracion de la pregunta a Rick, en cuanto al tema de los indices, si intento aprovecharse de la nobleza de Jario tal vez penso que era el chapulin colorado, pero, el problema radica en el disco que debe tener alimentacion constante de energia, por otra parte las tablas nativas para escribir un registro minimamente hacen dos accesos a disco sin contar con los indices, primero modifican el encabezado del dbf para actualizar el contaor de registros y luego escriben el registro en ese lapso ocurre un problema en la red de energia electrica y la proxima vez que abres el dbf ya te sale error de tabla corrupta, en el caso de los indices pasa algo parecido, para preveer el problema tienes que dar la instruccion al ususario de tu programa que debe reindexar las tablas cada vez que se produce un apagon o cada vez que aparece la pantalla azul (de la muerte), ademas, debes habilitarle un proceso para  que el usuario pueda realizar copias de backup, de esa forma te lavas las manos si hay problemas con la energia porque los clientes siempre te diran que no paso nada y que el sistema dio el error, ese problema del VFP sera corregido con la version Visual freePro que ya esta en fase de consultas no te preocupes que en el futuro tendras un vFreePro ya sin ese inconveniente.

Saludos.

[Fox Learner]

Gracias Walter por del Try Catch y las ideas..

Gonzalo, 

He usado sistemas que trabajaban con índices de Visual Foxpro y tenían su utilería tanto externa como interna de regeneración de índices e incluso la de restablecer back up o la de re-crear bases de datos. Tambien he usado programas basados en "Clipper o tipo Xbase" que regeneraban los índices antes de emitir reportes o hacer cálculos.

Incluso el SAE no sé en qué tecnología estaba basada la versión winbugs 2.5 (por aquello de los bugs jeje) traía un módulo completo de regeneración de índices por módulos. Claro que el mismo sistema te advertía que debías purgar a todo usuario del sistema antes de llevar a cabo el proceso. Ahora me atrevo a pensar que ese SAE talvez era Fox ya que no sé si Delphi usaba algo como índices....

En ninguno de los casos anteriores, para mi como usuario, esto representó ningún inconveniente. Si se caía el sistema de nómina, iba a la ayuda del sistema, veia como "levantar" el sistema cuando no te dejaba a entrar, corria la utilería externa de regeneración de indices y un unos segundos el sistema estaba funcionando de maravilla.

Si no hay forma de prever lo de lo índices (o talvez con try catch se logre..), solo tendría que hacer las utilerías, Documentarlo en el manual del usuario y dejarlo bien claro a todo usuario en la capacitación.

Gracias!!

[Edgar Acevedo]

Amigo FoxLerner:

Yo vengo haciendo programas desde los tiempos de Foxpro para DOS 2.6:  Año 1,990. Hice mis primeros 6 sistemas completos entre 1,991 y 1,996.  Totalmente los  6  siguen funcionando (aún en Windows 7 32 bits).  Quedaron tan sólidos, confiables y prácticos, que aún hoy, 20 a 22 años después SIGUEN SIENDO USADOS.  Los clientes NO los han querido cambiar.  Por ello hasta hace apenas 2 años me mudé a VFP 9. Pero estos 6 sistemas "grandes" siguen operando.  Uno de ellos en una red local con 64 estaciones y 18 estaciones remotas vía VPN.

Hasta la fecha te puedo asegurar lo siguiente:

- Ni con corrupción de datos o índices Fox me ha hecho cosas "absurdas" como que la suma de 1000 + 1000 sean 5000.  O que   4000-2000 sean 1000.

- Cuando hay problema con los índices, el mismo Fox te lo hace saber.  No recuerdo el mensaje de error (porque el último que tuve fue hace como 5 años), pero te lo dice.

- Cuando hay corrupción de datos, también el mismo Fox lo hace ver mediante un mensaje de error. Salvo en muy raras excepciones cuando la corrupción de la tabla ocurre a medio archivo.  Pero en estos casos son tus "técnicas" de programación las que definen el asunto.  También, fue hace como 8 años que me sucedió un caso se estos, pero como mis programas los hago utilizando una técnica de "referencia cruzada" de saldos, el descuadre saltó a la vista mediante reportes de verificación alternos.

- El cliente abusivo y tacaño SIEMPRE encontrará excusas para no pagarte.  Si en vez de sistemas, vendieras pantalones, se quejaría de que el tiro le ha quedado muy corto y le aprieta los huevos.  Si vendieras tiendas de campaña, se quejaría de que los manuales son confusos o que le diste los tubos equivocados.  Casi siempre en las primeras 2 entrevistas previas a presentar tu cotización, se conoce como será tu cliente:
  - Si se perfila como un maldito arrogante busca pleitos, sube tus precios, para que las "chingaderas" al menos, sean por una buena tajada económica.
  - Si se perfila como un sujeto afable, "razonable" y educado, baja tus precios, para que te siga dando trabajo, que aunque no sea el mejor pagado, será una especie de "gota contínua" que te dará lo necesario para subsistir decorosamente.

- Programar NO ES SOLO saber usar Fox.  También implica utilizar técnicas de programación seguras y "redundantes" que te ayuden a ver si hay descuadres.  Como soy un burro, yo no apréndí esto por mi mismo (muchos otros, autodidactas brillantes SI lo han desarrollado por sí solos), lo aprendí cuando estudiaba ingeniería en la universidad (Estructuras de Datos I, II y III).  En lo personal, utilizo cierta "redundancia" en la estructura de datos de mis archivos para que si por ejemplo, se me perdieran registros de las facturas que debe un cliente, en otro lado he guardado una bitácora de las facturas que fueron guardadas en su momento y de esa forma puedo saber si le "faltan 3 o mas pelos al gato".  Utilizo la técnica de "hacer cierres" y mandar los datos a "tablas históricas" que solo son READONLY (solo lectura) y que por lo tanto, no hay operación ni transacción que pueda dañar datos.

- Soy lo suficientemente viejo como para haber visto ya muchos casos catastróficos de pérdidas de valiosa información sucedida en entornos de Oracle, Sybase y SQLServer (en oficinas del gobierno principalmente, donde te contratan por "quien te recomienda" y no por tu "comprobada" capacidad y experiencia).

Salu2,


Edgar Acevedo

--
 
 
 

[Fox Learner]

Edgar, gracias por compartirnos tu experiencia. Es bueno estar en un foro que tiene tantos analistas experimentados y no solo "desarrolladores". Saludos!

[Guillermo MDQ]

Concuerdo con los comentarios de EdgarGt.
Aqui parece que le tuvieran terror a la corrupcion de tablas e indices como si sucedieran cada 15 minutos de uso del sistema.
Tengo muchos sistemas que trabajan con tablas nativas del fox trabajando desde hace años y algunos jamas han tenido problemas de corrupcion de indices o tablas.
Y en otros ha pasado en contadisimas ocasiones.
Todos los clientes que tengo trabajan con el equipo que tiene los datos conectado a una UPS, que es la mejor manera de minimizar los problemas causados por los cortes de energia.
Y teniendo los backups al dia y las rutinas de indexacion correspondientes no hay manera para asustarse tanto de que se corrompen los indices.
Y si llega a ocurrir un imprevisto, pues te llamaran para solucionar el problema y aprovechas para cobrar unos dinerillos por ello.

Saludos
Guillermo




c

[Neyger Pérez Mayo]

 

Me hicieron recordar

 

 

Yo sufri  bastante con los indices cuando se trabaja en msdos y el cableado era con cable coaxial, en la era del NetWare y el  lantastic.

 

Y cuando el origen del problema era una tarjeta de red dañada o que estaba por fallar, como se corrompian los indices.

 

 

[leonardo trujillo]

interesante tema
alguien me podría orientar de dónde conseguir "utilería tanto externa como interna de regeneración de índices e incluso la de restablecer back up o la de re-crear bases de datos" 
¿qué mecanismo usan para que esto sea "automático" y lo pueda hacer el usuario del sistema cuando aparecen estos errores?
muchas gracias

 

 

--
 
 
 

[Hitiel Hernández]

yo utilizo un código como este:

thisform.proceso

*!* REINDEXAMIENTO DE TABLAS DEL SISTEMA Y DE LA CARPETA PERIODO (ACTUAL)

CLOSE DATABASES

LOCAL intervalo, progressbar2,archivo

intervalo = 0

progressbar2 = 90

thisform.progBar.max = 90

****************** TABLAS DEL SYS\DBF ************************************

IF USED(_data+'tablas\bodegas.dbf')

MESSAGEBOX( "TABLAS ABIERTAS .... CIERRE LA APLICACION POR COMPLETO ")

RETURN

ELSE

USE _data+'tablas\bodegas.dbf' EXCLUSIVE &&&&&& Esta es la primera Tabla

PACK

DELE TAG ALL

Intervalo = intervalo + 1

thisform.progbar.VALUE = intervalo

INDEX ON codb TAG codb additive

Intervalo = intervalo + 1

thisform.progbar.VALUE = intervalo

INDEX ON descripb TAG descripb additive

Intervalo = intervalo + 1

thisform.progbar.VALUE = intervalo

thisform.archivo.Caption = 'Archivo:'+_data+'tablas\bodegas.dbf'+ '...Indexado!!'

WAIT WINDOW thisform.archivo.Caption timeout(0.25)

Intervalo = intervalo + 1

thisform.progbar.VALUE = intervalo

ENDIF

--
 
 
 

--
Sabiduría ante todo; adquiere sabiduría

[Dario Baca]

Los indices corruptos se presentan por lo general a causa de problemas electricos, y la mejor solución es contar con una UPS.

 

Algo que a mi me funciono es colocar el comando FLUSH luego de cada escritura en la base de datos, esto reducirá notablemente los problemas con los indices o tablas corruptas.

 

Saludos,

 

 

 

Dario Baca

[leonardo trujillo]

Entonces, cuando los índices se corrompen ¿hay que borrarlos y volver a crearlos?
¿quiere decir que si tengo 20 tablas con 3 índices cada una tengo que crearlos en cada una de ellas?
gracias

--
 
 
 

[Edgar Acevedo]

NUNCA  se dañan todos juntos. Solamente se daña el archivo CDX de la tabla que estaba siendo modificada durante el momento que se dió el problema de hardware que originó el problema:

- Falla en el fluído eléctrico y el UPS falló al entrar a funcionar o simplemente no había UPS
- El usuario pulsó el botón RESET del computador justo en el momento que la tabla se estaba modificando
- La conexión de red local falló (se safó el cable, una rata modrió el cable, etc)

El caso mas grave de índices dañados lo ví en 1998 (lo recuerdo bien porque acababa de casarme).  De 24 tabalas que estaban en uso, solo se dañaron los CDX de 3 tablas.  Razón: la señora de la limpieza pasó la escoba detrás del servidor y jaló el cable de potencia, apagando inmediatamente el servidor.  Habían 22 estaciones accesando y operando sobre la aplicación de Foxpro DOS 2.6 que utilizaba las tablas.

El programa indicaba claramente cuales eran las tablas que tenían dañados sus índices.  Los usuarios corrieron un programa que reparaba índices dañados (borrándolos y construyéndolos de nuevo).  La operación de reparación tomó 25 minutos.  Desde el año 1,998 hasta hoy (14 años después) la aplicación sigue operando y no han vuelto a tener problemas con índices.

El siguiente problema de índices dañados lo tuve allá por el año 2,003 (ahora si no estoy muy seguro del año...).  Sucedió en el Aeropuerto Internacional "La Aurora" de Guatemala.  Una aplicación que trabajaba con 18 tablas abiertas dejó de responder y luego apareció un mensaje de error de red.  Sucedió que unos albañiles estaban haciendo un trabajo de reparación de unas lozas y pasaron cortando el cable de red por error, justo en el momento que se estaba grabando un ingreso de mercadería (como de 500 artículos). 

Una vez mas, una vez restablecido el problema del cable.  La aplicación hecha desde 1,992 en Foxpro DOS 2.6, indicó que el archivo CDX de la Tabla "MOVPROD" se había dañado.  El usuario procedío a indicarle que si quería que reconstruyera el índice, el programa lo hizo y en 10 minutos ya estaban trabajando normalmente.

Salu2,



Edgar Acevedo

--
 
 
 

[Hitiel Hernández]

excelente acotación

--
 
 
 

[leonardo trujillo]

gracias edgardo
me queda claro que sin problemas de red y de eléctrica, no debería tener problemas.
de todas formas debo pensar en los riesgos y ante ellos contingencia.
muchas gracias

--
 
 
 

[Carlos Miguel FARIAS]

Tengo sistemas funcionando con 17 años, donde los indices no se si rompían.
Algo muy simple, controlo que si el sistema no cierra bien, los indices los reconstruye a medida que va abriendo las tablas.
El control muy simple, cuando abro una tabla, marca en un archivo mem guardo que la tabla esta abierta. Y se desmarca al cerrar. Si cuando va a abrir, detecta que ya estaba abierta, quiere decir que no estuvo bien cerrada y por lo tanto, dispara un reindexado (se haya roto el indice o no).
Por supuesto que, con cortes de luz o plantada de la computadora, siempre queda algún dato con errores (inconsistente), pero eso no se puede solucionar si no se arregla el registro a mano o como en la mayoría de los casos, se recurre a una copia de seguridad.
Saludos: Miguel, La Pampa (RA)

--
 
 
 

[Arnaldo Toledano]

Te comento lo que hacia cuando utilizaba dbf e indices.
1.- Crea una función para abrir cada tabla.
Por ejemplo
If AbreCabFac()

Donde la Función AbreCabFac abre la tabla y TODOS los indices asociados.
Cada vez que abras la tabla, al utilizar la misma función, no tendrás oportunidad de abrir menos indices que los asociados.

2.- Crea una función para RE INDEXAR, de tal manera que sea siempre la misma.
Otra manera de evitar crear mal los indices.

3.- Cada vez que abrís el sistema, reindexa todos los archivos del sistemas.
Al principio es engorroso, pero una vez que se acostumbran, ya saben que tienen que abrir el sistema 5 minutos antes de empezar
a trabajar. OJO, utilizando siempre las funciones del punto dos.
Para que el indexado se realice UNA SOLA vez, crea un dbf con un campo que contenga la fecha NADA MAS.
Al abrí comparas las fecha del sistema con la fecha de la tabla, si son distintas, REINDEXA.

Arnaldo Toledano

--
 
 
 

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