Base de datos corrupta

vForum público de la plataforma de desarrollo Velneo

Moderador: vCoaches

Avatar de Usuario
glpunzi
vMate
vMate
Mensajes: 94
Registrado: 02 Dic 2008, 15:22
Ubicación: Murcia
Contactar:

Mensaje por glpunzi » 21 Dic 2008, 00:10

Uhmm...viendo que en el campo ticket, hay un valor, 0-Ago-25. Si ese campo está definido como fecha, es un error que pueda aceptar ese valor.
Skype y google talk: glpunzi

http://www.lordzealon.com

Avatar de Usuario
fgutierrez
Velneo
Mensajes: 62
Registrado: 11 Sep 2007, 22:43
Ubicación: Xixón, Asturies

Lo que puedo ver

Mensaje por fgutierrez » 21 Dic 2008, 02:03

Yo, lo que puedo ver a simple vista sin hacer lo que te comentan, ver el orden cronológico en que se introdujeron los datos, es que tienes varios contadores, entiendo que entre ellos el campo código con siguiente al último, que admiten más de cuatro bytes (imagino que 6 bytes), pero éste último no puede ser de ese tamaño.

El tamaño máximo del campo código es de 4 bytes, es decir, unos cuatro mil millones de registros (4.000.000.000). Sin embargo veo que tienes un campo código que admite mayores valores, por lo que eso ya está mal de base. Y veo que el número de ticket se calcula en función del código. ¿Puedes estar modificando el campo código en algún proceso? ¿Puede que en función del campo número de ticket?

Revisa por otro lado que no tengas ningún campo definido en la tabla con menos bytes de los que necesita. Por ejemplo que tengas un contador de dos bytes, cuando ya ha superado los 65535 registros.

Si la tabla es compartida con otras aplicaciones, comprueba que están definidas de igual forma en todos los mapas.

¿Alguno de los contadores se calcula en función a algún puntero? Puede ser otra pista. O si se calcula en base a una variable que no tiene un tamaño adecuado.

Pero el trabajo que has de hacer es el que te comentan, revisar los datos por orden cronológico y ver dónde se da el salto. Te recomiendo que lo hagas sobre una rejilla de tabla de datos completa.

También sería interesante saber si estás con cliente servidor o monopuesto.
fgutierrez (aka Tito)
Velneo
Localización

Avatar de Usuario
Adelo Herrero
vAdviser
vAdviser
Mensajes: 714
Registrado: 21 Sep 2005, 14:42
Ubicación: Requena (Valencia) - España - (Lat: 39.490701 * Lon: -1.102329 )
Contactar:

Mensaje por Adelo Herrero » 21 Dic 2008, 07:37

Dices que te ha ocurrido en distintos clientes, por lo que debe ser un fallo en la aplicación y no del sistema, hard, antivirus, parches de seguridad, etc.

Sería interesante conocer algo más del funcionamiento del programa, por ejemplo ¿trabajas directamente por VATP? ¿terminal server? ¿Local actualizando con funciones remotas? ¿procesos de importación como decía MGalvez?

Ese tipo de cosas ayudaría a estimular la neurona :)

Por otro lado, si tienes procesos de "cierre de caja" o "cierre de turno" verifica si escribes en esas tablas por proceso, sobre todo fechas, punteros indirectos y los índices que los resuelven, pues los años "raros" de la fecha influyen en el tamaño del campo ticket.

De todos modos, comprueba que no compartes la tabla con otras aplicaciones y que no hay otras aplicaciones que usen tablas que se llamen igual aunque sean para un fin distinto, claro.

Calma, paciencia y suerte, y si nos das más datos echaremos una mano en lo que se pueda.

Un saludo.

Francisco Hoyos
vLeader
vLeader
Mensajes: 2712
Registrado: 22 Sep 2005, 17:56
Ubicación: Gijón (Asturias) España GMaps: 43.538740, -5.661970

Mensaje por Francisco Hoyos » 21 Dic 2008, 10:54

Después de mirar con atención las pantallas de datos y leer las opiniones de los foreros, empiezo a descartar (aunque no del todo) el que estén chocando dos versiones de la misma tabla y me parece más probable la opción de que estés importando tickets con una estructura errónea.

En cualquier caso, es mucho más interesante ver los volcados de una tabla usando la opción Rejilla tabla datos completa. Puede aportar pistas que en una rejilla normal no se aprecian.

Un saludo.
Francisco Hoyos
frhoydon@gmail.com

bannu
vCool
vCool
Mensajes: 175
Registrado: 10 Jun 2006, 22:42

Mensaje por bannu » 21 Dic 2008, 15:44

Vamos por partes, ¿los campos código no admiten más de 4 bytes?, pues porqué permite modificar el campo código de 4 a 6 bytes, esto que quiere decir ¿qué cualquier campo que lleve un índice numérico debe ser de 4 bytes?.
Por otra parte, el campo número de ticket toma el valor de un contador numérico (longitud 6 bytes) no del campo código, no se importan datos, a las tablas, el campo código no se modifica en ninguna parte del programa, otra cosita, si fuese un fallo del programa ¿fallaría siempre y con todos los clientes, o no?, ¿puede ser que al colgarse el TPV y al salir el diálogo de reparar el cliente cancela dicha reparación?

Avatar de Usuario
fgutierrez
Velneo
Mensajes: 62
Registrado: 11 Sep 2007, 22:43
Ubicación: Xixón, Asturies

Transacciones

Mensaje por fgutierrez » 21 Dic 2008, 16:59

El campo código, como tal, no admite más de cuatro bytes. Está en las especificaciones. Pero tú, como programador, puedes cambiar el uso de ese campo y cambiarle las propiedades, pero entonces no has de usarlo como campo código. Los campos numéricos admiten hasta 6 bytes pero no cuando son usados como campo código.

Por otro lado, acabas de comentar una cosa a tener en cuenta. Si la aplicación se cuelga y al iniciar no reparamos, las tablas quedan bloqueadas hasta que el usuario las repare. Si éstas se usan para otros cálculos, ten en cuenta que no transaccionan, por lo que estarán generando problemas en el caso de que se necesite. Si, además, borras el fichero de transacciones para que no se realice la reparación, cómo queden los datos entenderás que no queda garantizado.

Pero, en principio, para el diagnóstico, comienza por ver la secuencia de los acontencimientos y revisa los procesos que afectan al campo código, sobre todo esos. Y si los modificas por proceso, con mayor motivo.

Si tienes el campo código de 6 bytes es lo primero que tienes que corregir.
fgutierrez (aka Tito)
Velneo
Localización

Francisco Hoyos
vLeader
vLeader
Mensajes: 2712
Registrado: 22 Sep 2005, 17:56
Ubicación: Gijón (Asturias) España GMaps: 43.538740, -5.661970

Mensaje por Francisco Hoyos » 21 Dic 2008, 16:59

¿los campos código no admiten más de 4 bytes?
Si te fijas bien, en el asistente para la creación de tablas, los campos código de naturaleza numérica aceptan hasta 4 bytes.

Sin embargo, los campos numéricos aceptan hasta 6 bytes de longitud. Entiendo que se pueden indexar campos numéricos de 6 bytes. Lo que no te permitirá es un índice con más de 4 mil millones de entradas. Al menos eso es lo que yo entiendo.
¿puede ser que al colgarse el TPV y al salir el diálogo de reparar el cliente cancela dicha reparación?
Te comento esto suponiendo que estás trabajando con la versión monopuesto.

Si el cliente cancela la reparación, Velneo bloquea la/s tabla/s que se ven involucradas en la transacción que ha provocado el problema. Intentar trabajar con alguna/s tabla/s bloqueadas puede ser todo un problema, si es que realmente llega a permitir que se pueda trabajar.

Hay dos opciones, o se repara (opción más sensata), o se sale y se elimina el archivo de transacciones (tendremos una base de datos con incoherencias).

Por otra parte, sería muy importante averiguar la causa que cuelga al TPV. Porque si además afecta a los índices de las tablas, el caos puede ser de órdago. Lo digo porque me volví loco en una franquicia hasta que descubrí que ponían junto al TPV una máquina herramienta con un campo magnético brutal. Cada poco se volvían locos los índices y se saltaban la numeración. La verdad, lo raro es que funcionara el ordenador.

Espero que resuelvas pronto el misterio.

Un saludo.
Francisco Hoyos
frhoydon@gmail.com

Francisco Hoyos
vLeader
vLeader
Mensajes: 2712
Registrado: 22 Sep 2005, 17:56
Ubicación: Gijón (Asturias) España GMaps: 43.538740, -5.661970

Mensaje por Francisco Hoyos » 21 Dic 2008, 17:02

Joer, Tito, lo hemos clavao :lol: :lol: :lol:

La hora y las observaciones.

Un saludo y Felices Fiestas.
Francisco Hoyos
frhoydon@gmail.com

bannu
vCool
vCool
Mensajes: 175
Registrado: 10 Jun 2006, 22:42

Mensaje por bannu » 21 Dic 2008, 19:37

los campos numéricos aceptan hasta 6 bytes de longitud. Entiendo que se pueden indexar campos numéricos de 6 bytes
Si los índices numéricos no permiten más de 4 bytes no debería estar permitido desde el vEditor crear un índice de un campo numérico de 6 bytes, o al menos debería saltar un mensaje de error o aviso tipo: “No se permite indexar campos numéricos superiores a 4 bytes”, como tampoco debería estar permitido cambiarlo desde las propiedades del campo, pero en fin, una vez que se sabe no tiene mayor problema, lo que necesito saber con certeza es si todos los índices numéricos están limitados a 4 bytes.

Por cierto la corrupción de la base de datos no sigue un patrón definido, es aleatorio, en la imagen se ve perfectamente.

Gracias por la ayuda a todos, pero me interesaría saber si alguien le ha ocurrido algo parecido, desaparición de datos, tablas corruptas, en el foro existen varios post con sucesos similares y quiero descartar que sean bugs en la versión actual de Velneo, con la versión anterior (6.4.0), y a pesar de tener los campos código a 6 bytes nunca me había pasado algo así.


Imagen

Avatar de Usuario
pacificador
vAdviser
vAdviser
Mensajes: 670
Registrado: 27 Sep 2005, 20:47
Ubicación: Huelva
Contactar:

Mensaje por pacificador » 21 Dic 2008, 21:07

A mi no me había pasado esto nunca, en cuanto a lo de las fechas si lo he visto, es cuando se calcula el año con la función fEdad() y tiene formato de fecha salen esos dígitos, si se pone alfabetico sale la edad bien, con los números pasa igual, pero claro lo que no he visto que el mismo campo con la misma definición aparezcan de forma distinta como es este caso. Vuelven los famosos fantasmas de Velneo.
salu@s velazquianos

google maps +37° 39' 10.04", -6° 52' 48.33"

Responder