dbf registros eliminados se muestran en mysql

[jdyerovi]

Bueno compañeros tengo un super problemon les explico

Tengo una aplicacion contable en fox de la empresa que trabajo, no pdodemos salir de ese sistema. la cuestion es que como las tablas ( DBF ) no son muy seguras estoy migrando a mysql cierta informacion.

Ya logre migrar la informacion, lo hago en PHP por odbc usando las sentencias SQL pero aqui biene el problema se me pasa todo incluso los registros borrados que hace fox logicamente.

El problema es que no puedo hacer un pack de la base porque es un historico que tiene esa bendita aplicacioón, y por SQL no se como ocultar esos registros como se hace en fox que es

SET DELETED OFF

o

SELECT DISTINCT(DELETED()) FROM TABLA

pero en SQL no existe eso DELETED(), no se como hacer ya eh indagado en google y no consigo como resolver este problema, si alguien se a topado con eso de migrar archivos dbf a mysql y sin hacer pack poder ocultar esos registros borrados para poder pasarlo a mysql estaria muy agradecido


Saludos
Un Desarrollador en problemas

[gnzsoloyo]

El primer problema que tienes es que Fox no es un DBMS, es apenas un manejador de tablas. Sus recursos son muy limitaos, como sin dudas te habrás dado cuenta, y además sus métodos inseguros y poco eficientes.
Pero lo más importante en tu caso es que la forma de manejar las cosas es muy diferente entre ambos (fox y MySQL). El borrado es una muestra del caso.
En los DBMS, a diferencia de los archivos .dbf, el borrado es físico, por lo que un DELETE consolidado hace desaparecer realmente a los registros, mientras que Fox lo que hace es agregarle una "marca" de borrado, pero no lo selimina hasta que las tablas efectivametne no son optimizadas. Es decir que hace lo que se denomina un "borrado lógico", no físico.
Pero cuando importas un DBF a un DBMS como MySQL, la "marca" es interpretada como una columna especial, si mal no recuerdo de tpo VARCHAR, nada más. para MySQL eso no significa nada porque, como dije, un DELETE en MySQL tiene un efecto real.
Lo que se hace en este caso es simplemente realizar la consulta de modo que no devuelva los registros donde ese campo tenga esa "marca" (que si mal no recuerdo aparece como un asterisco), y nada más.
Cuando diseñas las bases de datos en un DBMS el problema del borrado físico se resuelve de un modo sencillo: Se le agrega a las tablas un campo adicional, usualmente de fecha o fecha y hora, que se usa para indicar la "Fecha de Baja", de modo que si es NULL, el registro está vigente, y si tiene una fecha, está "borrado", sin ser eliminado.
Pero eso se hace para evitar problemas de integridad referencial, y no por otras causas.

¿Se entiende la idea?