Se puede verificar la "salud" de las tablas dbf ?

[Ultraton500]

Buenas tardes colegas,

cada vez que se corta la electricidad o se me cuelga la máquina mientras estoy usando vfp me pregunto si alguna de mis tablas se dañó y quién sabe cuándo lo voy a descubrir. Por eso es que me puse a averiguar cómo diagnosticarlo pero no he podido encontrar nada al respecto.

Alguien podría indicarme cómo se hace si es que se puede?

Utilizo vfp9.

Desde ya muy agradecido,

Saludos,

Javier.

[Jorge L. Florez C.]

Y porque no usar un UPS?

Saludos

Jorge Florez

Lima - Perú

[Ultraton500]

Y qué hago con un UPS si se me cuelga la máquina por fallas o virus?

Además.. no puedo exigirle a los usuarios la compra de un UPS.

Antes del motivo del uso o no de un UPS se podría preguntar ¿por qué no usar un motor de SQL?... pero bueno, por el momento el problema es el que planteo por lo que si tienes alguna respuesta que me sea de utilidad te lo agradeceré.

Saludos,

Javier.

[Fernando D. Bozzo]

Javier:

Este tema se habló largo y tendido en el foro. Mejor que curar (ver si los DBFs están bien), es prevenir, que lo podés hacer dejando las tablas cerradas todo el tiempo y abrirlas solo en el momento de necesitar guardar, para volver a cerrarlas. Así como "en boca cerrada no entran moscas" pdríamos decir que "tabla cerrada no se corrompe" :-)

Ahora, si tu desarrollo lo hiciste de la forma tradicional, o sea, no en capas, y tenés las tablas todo el tiempo abiertas porque las mostrar con grids, entonces lo tenés más difícil.

No conozco programas que verifiquen esto, pero un chequeo en profundidad sería costoso, porque hay distintos tipos y niveles de corrupción, desde el más simple de que no se actualizó o se perdió el contador de registros del header de la tabla hasta el más groso donde parte de la información de la tabla o del memo se sobreescribió con basura, y cuyo arreglo no recupera los registros de los datos dañados.

Por eso se insistió tanto en usar una BDD más robusta como SQL Server, MySQL, MariaDB u otras.


Saludos.-

[HernanCano]

Para abrir mis DBFs, no utilizo "USE ARCHIVO.DBF SHARED" por toda mi app.
Lo hago así:  DO ABRIR WITH "ARCHIVO.DBF"
Tengo una procedure (¿ó PRG? ABRIR.PRG) en la que centralizo la apertura de archivos de datos y ahí hago lo sgte por cada una:

- Verificar si el DBF existe (aunque en ambientes de red muchas veces tuve dificultades: Windows no se conecta al servidor siempre, y aquí podía fallar, pero en los sgtes ya no).
- Verificar si el DBF tiene cero bytes de tamaño.
- Verificar si el tamaño del DBF tiene el mismo tamaño que me devuelve RECSIZE()*RECCOUNT más algún ajuste que encontrarás en Internet.
- Verificar si el IDX ó CDX que necesite existe.
- Verificar si el CDX tiene cero bytes de tamaño, o cualq otro IDX ó CDX que necesite para ese DBF.
- Verificar si el FPT existe.
- Verificar si el DBF ya está abierto de modo exclusivo por otro usuario.
- Verificar si el DBF ya está abierto de modo compartido por otro usuario y aquí se necesita exclusivo.
- Debería verificar si el archivo tiene un campo AutoInc que pueda ser usado como índice Principal o Candidato, y no se ha creado este indexado, pero no lo he implementado.

Para los dos segundos casos el mismo procedure puede solucionar basado en una rutina que encontrarás en Internet.
Para los demás, se informa del error, e informa que no se pudo abrir el DBF. Si el error es que los indexados no existen, voy a Reindexar (que no es estrictamete ejecutar REINDEX) para regenerar los indexados.

Para el primer caso le pido al usuario que minimice la app, vaya al escritorio y abra el Explorador de Windows y haga click en la letra S: que corresponde al servidor (es una app FPW 2.6 y no quise buscar la forma de hacer NetGetConnect), de ésta forma ya puede volver a la app y continuar.

Hay un caso que nunca pude resolver, era un DBF de FoxPro 2.5 DOS.
El archivo tenía un memo .FPT, y debido a algún cerrado brusco de la app, ya nunca pude ejecutar PACK (me parece que sí podría ejecutar PACK MEMO). En el DBF se podía abrir, ingresar registros, modificar registros, borrar registros, los indexados se actualizaban bien; pero ya nunca pude ejecutar PACK, pues me marcaba un error que no recuerdo. Desafortunadamente dada la naturaleza de la app, no podía prescindir de ese campo memo.

Seguro que hay más casos, pero en este momento son los nueve que tengo en mente.

[Ultraton500]

Fernando:

Gracias por la respuesta.

Totalmente de acuerdo con que mejor que curar es prevenir. La razón de mi consulta es que estoy teniendo cuelgues a los que nos viene costando encontrar la causa y necesito usar la máquina por una cuestión de plazos.

En realidad estoy terminando una aplicación empezada con tablas dbf y ni bien lo haga comienzo la migración a Firebird por lo que la forma de trabajo es usando solo cursores. 

Hernán:

Gracias por la información que es muy detallada. Es una buena idea que podría implementar.

Saludos cordiales,

Javier.

[Alejandro Isla]

¿Con un pack y reindex no alcanza para verificar que la tabla esté OK?. Según la forma de trabajar del pack "Cuando se ejecuta PACK, Microsoft Visual FoxPro copia todos los registros que no están marcados para borrar a una tabla temporal. Cuando se termine de ejecutar PACK, Visual FoxPro eliminará la tabla original del disco y cambiará el nombre de la tabla temporal por el nombre de la tabla original"

Es decir, tenes un acceso físico a cada registro y copia del mismo, si hace pack, la tabla está ok.

[Ultraton500]

Es un muy buen dato Alejandro. Voy a ver si puedo automatizar ese proceso. Así que muchas gracias por la respuesta, me parece muy interesante.

Saludos cordiales,

Javier.

[Fer]

Hola :

Cuando se trata es verificar datos, si hay corrupción un pack puede ser catastrófico y hasta podría dejar la tabla vacía.

[Carlos Miguel FARIAS]

El solo reconstruir los indices, hacer un pack, no indican para nada que no haya corrupción de datos.

Es más, puede haber corrupción de datos con las tablas "físicamente saludables".

Lo menos que se debe hacer es correr un programa que recorra todos los registros y verifique que cada uno de los campo contengan datos en el rango, enumeración etc que las reglas de negocio permiten.

Si son las columnas que corresponden a claves foráneas, constatar que el lado uno exista.

Si son datos críticos, por razones de auditoria, debería tener un timestamp (o sea, un atributo que al tocar el registro, carga la fecha de modificación) o aún mejor, un checksum (p.e. sys(2017,...) para ver si la suma de control del registro, coincide con los datos del registro.

Esto último puede detectar corrupción de datos producidos por fallas operativas, o manoenlata. Y si es posible, los datos importantes, deben apilarse en una bitácora de cambios, para poder constatar, quien, cuando, como, donde (las 4 W Who, When, How y Where) hizo el cambio y porque.

Sin esos controles, no se puede asegurar minimamente que las tablas no estén "malamente adulteradas"

Saludos: Miguel, La Pampa (RA)

[Ricardo Pina]

Hola Hernan

Estaba leyendo tu post, lo lei un par de veces y no le veo cuál es la ventaja de abrir las tablas de esa manera.

La mayoría de mis formularios no bajan de 30 tablas y suelo abrir casi todas en el Dataenvironment que creo es la forma más rápida de hacerlo.

Si haces esas verificaciones en todas tus tablas no resulta muy lenta la carga de los formularios ?

No sería mucho mejor verificar todo eso en algún procedimiento que recorra todas las tablas del sistema al comienzo de la aplicación con algún lindo cartel "Espere estamos trabajando para usted"

Me estoy perdiendo algo ?

Saludos

--

            

                   Ricardo Pina

Desarrollo y Servicios Informáticos

                  Profesionales
               www.dsip.com.ar

 

 

[edgar suarez kummers]

(las 4 que son 5 ........... Who, Why, When, Where, How)

El famoso:

¿ Quién ?, ¿ Por Qué ?, ¿ Cuándo ? , ¿ Dónde ? , ¿ Cómo ?

Porque cuando donde yo como .......... sirven mal protesto.

edgar suárez kummers

[HernanCano]

Sí, Ricardo. Gracias por participar.

Hasta eldía de hoy no se nota lentitud en la carga de formularioS, pero lo que dices es cierto. Lo tomaré en cuenta para optimizar.

La ventaja es lo que pide Javier (ultraton): detectar la "salud" de los archivos de datos automáticamente.

[HernanCano]

Alejandro,
Fernando,
Miguel:

El hecho de ejecutar un PACK no determina la salud de los DBF, en éso tienen ustedes toda la razón. Mi comentario no fue para indicar que "un PACK resuelve": sí digo que "un PACK optimiza (elimina marcados para borrar)".

Con el ejemplo que puse sobre PACK, lo que quise significar es que no pude saber cómo detectarlo ni cómo resolverlo.

Pero chicos: el tema está cerrado por el preguntante inicial. Así que obedezcamos la regla, ¿listo?

[Carlos Miguel FARIAS]

La metodología de Hernan pareciera similar a la que uso.

En mi caso, al abrir una tabla, registro en disco que esta abierta, quien y cuando la abrió y en que modalidad.

De esa manera, por ejemplo, si alguien necesita la tabla en exclusiva, deja marcada la tabla como apertura exclusiva pendiente. Las otras aplicaciones, que utilizan el mismo procedure para abrir, detectan tal circunstancia y pueden mandar un aviso a los otros usuarios/aplicaciones para que cierren al menos el uso de esa tabla y cuando todos la liberaron, el peticionan-te puede ejecutar su solicitud de uso exclusivo.

Cuando alguien cierra una tabla, marca como que no la esta usando y ya esta.

Un programa administrador central, puede correrse en el servidor para detectar si hay tablas abiertas y no cerradas. Lo que puede indicar (si hace mucho que están abiertas sin cerrar) de que alguna aplicación termino mal y amerita efectuar una reindexación o un control de integridad como el que indique antes.

Las dbfs, con los recaudo correspondientes, pueden usarse con muchos usuarios y muchos registros.

Por supuesto que, es mucho mejor usar un SGBD, pero cuando el usuario no cuenta con alguien en el área de sistemas (o un área de sistemas, siquiera) que tenga algunas luces para hacer un backup mas complejo que apretar un botón, salvo Firebird y alguna otro SGBD, no existen facilidades (simplicidad) para copias de seguridad.

SQLite por ejemplo, si hay usuarios concurrentes modificando, es muy lenta.

Con mysql, usando myisam, si se puede hacer más o menos lo mismo, pero myisam no maneja transacciones, por ejemplo.

Saludos: Miguel, La Pampa (RA)

FELICES FIESTAS PARA TODOS .......................... Y TODAS

[Ultraton500]

Muchas gracias Miguel, felices fiestas para vos también y para el resto de los compañeros del foro!!!.

Y gracias por todos los comentarios.

Saludos,

Javier.