pérdida de registros al insertar

[jurena]

amigos,
solo quiero algo de orientación a sabiendas de que son pocos los datos que puedo proporcionaros y mínimo el acceso que tengo a la base de la que os hablaré. Como veréis, no sé si el problema es de la base o del programa que uso para cargar los datos, un NAVICAT LITE. No tengo control sobre la base en el servidor más allá de este programa, que es algo limitado. Pues bien, cuando cargo registros nuevos en una tabla pequeña desaparecen otros de la misma, como si el espacio estuviese limitado. He comprobado la naturaleza de la PK de ambas tablas y está bien, INT 11 y primary key, con lo que por ahí no veo problema. He pedido a los técnicos que miren en consola, que hagan la importación en consola o con otro programa Workbench o PHPMyAdmin. Todavía no sé cómo han hecho lo que han hecho, importando de varias maneras, principalmente desde archivos con formato CSV, pero el problema persiste. Yo insisto en que si los datos se cargan, pero luego no se muestran, es problema de la programación que los muestra en el front, pero si desaparecen al insertarlos es cosa de la base o del programa con el que cargo. No tengo más acceso por ahora a nada, pero tal vez a alguno de vosotros le haya ocurrido algo parecido con alguna tabla o base de MySQL.

Gracias

[quimfv]

Como ya dices tu mismo nos puedes dar poca información, tan poca que es dificil que se pueda decir nada.

NAVICAT simplemente es un cliente para varios servidores de bbdd, eso no da ninguna información útil.

Por duplicidad de PK deberia darte error y no hacer nada...

[gnzsoloyo]

Realmente es un caso singular, que me hace recordar vagamente alguien que planteó una cosa semejante. Ya ni recuerdo con certeza el caso, pero tengo la idea que en ese caso había otros procesos corriendo que tocaban la tabla, y que no estaban definids ni en triggers, ni en SP, y eran esos procesos que se desconcçian los que generaban el borrado.
Por empezar, sería bueno que nos aclararas una cosa: Cuando se insertan registros, tal que sean menos que los que en ese momento existen en la tabla, ¿se borra la misma cantidad que entran, pero permanecen algunos de los que ya existían?
O bien: ¿Se borran todos los que se ingresaron? ¿Se borran los que estaban, pero aparecen los nuevos?

Sería interesante ver cómo escriben la consulta que carga el archivo CSV...

[jurena]

quimfv, gnzsoloyo,
esas mismas preguntas me las hacía yo. El problema, en una primera fase de su análisis era averiguar el número de los que se perdían, si siempre era el mismo número y dónde se perdían, es decir, si había algún parámetro que se repetía, pero como se habían perdido registros en diversas ocasiones, tampoco sabía el punto de partida. Iba a empezar a hacer un análisis más exhaustivo de eso cargando todos los datos que pudieran cargarse y haciendo COUNT, cada vez que cargara uno hasta llegar al límite, cuando me percato, con la inestimable ayuda de un colega informático, de que dos campos relacionados una PK y su FK presentan en la estructura distinta naturaleza, es decir, uno es INT (11) y otro INT (2) , confusión causada con un campo que añade también el número de mes. Lo he cambiado inmediatamente INT(11) y he podido añadir uno a uno todos los registros que se borraron y ahora no ha desaparecido nada. No obstante, queda hacer la prueba de insertar los datos de la estadística de este mes, cuando acabe, claro, y hacerlo como grupo de datos. Serán como 35 registros. Entonces comprobaré si el problema era ese o tendré que hacer lo que me sugiere gnzsoloyo en lo que respecta al cómputo de lo que se inserta y desaparece en cada ocasión.
Tal vez podáis confirmarme que esa diferencia de naturaleza puede causar algún problema de este tipo.

Gracias a ambos.

[gnzsoloyo]

Hay un vicio común al usar columna de tipo INT de usar ese valor entre paréntesis en la creencia de que restringe la representación delos valores del campo, cuando no es así. Pero si puede causar comportamientos anómalos cuando se trata de operaciones masivas, backups, y creación de vistas.
Es preferible dejar que el numero se lo ponga por default MySQL, o bien indicar el que realmente tiene (11 si es con signo, 10 si es sin signo) EVita complciaciones y malos entendidos.
Por otro lado, me llama la atención que haya una definición de FK que esté apuntando un campo definido como INT(2) a una PK INT(11), porque no debería dejar crear la FK en esas condiciones. Eso porque deben ser siempre exactamente iguales en tipo, rango, representación, etc.
Por su lado, dependiendo de la escritura del LOAD DATA, y si se usa o no LOCAL o incluso REPLACE y/o IGNORE, puede haber cambios en el comportamiento del comando. Estos cambios pueden afectar el caso de claves duplicadas o únicas.
Por eso preguntaba sobre cómo lo estaban usando.

[jurena]

gnzsoloyo,
lo dejó crear porque en realidad no son PK y FK, se trata de una base MyIsam que creamos en 2007. Son PK y FK a nivel de programación.
He vuelto a revisar y ver un poco lo del cómputo y lo que observo es que no deja que haya más de 1280 registros en la tabla. A ver si es número os dice algo. Inserto otras 35 y vuelve a haber 1280 (parece que es el número límite) y las nuevas están: está claro que borra otras. No sé cuál qué borra. Sí observo que hay algún dato que se repite, es decir, que desaparecen algunos que tienen en un campo el valor 5 y en otro el 3; o bien el 2 y el 1, etc. Voy a hacer otras pruebas. Intentaré descargarme la base o al menos esas tablas.

[gnzsoloyo]

Es bastante raro porque no hay restricciones a nivel tabla que puedan realizar esa tarea, aunque bien podría haber otyro tipo de procesos no visibles.
¿Hay triggers definidos en esas tablas?
¿Existen jobs en el servidor que la invoquen?
Un proceso que puede crearse es uno que se ejecute periodicamente y que verifique la cantidad de registros de la tabla para eliminar los antiguos; pero ese tipo de procesos no son por triggers, sino por SP, por ejemplo.
También se pueden hacer por EVENT en los servidores mas recientes.

Yo apuntaría a algun proceso en background.

[jurena]

No, que yo sepa, no tengo creados triggers, tampoco sé de ningún SP que esté funcionando. Y sí es raro, pero creo que no tan raro a nivel de base de datos, pues puede que el problema no esté en la base sino en ese cliente NAVICAT LITE, pues he importado la tabla y le he añadido una inserción con PHPMyAdmin sin problema, luego he vuelto a NAVICAT y ha permitido insertar también un solo registro. Es en la inserción mediante pegado en la que se produce el problema. Tendré que ver el modo de corregir los fallos y luego cambiar de cliente a otro que no me dé esos problemas. Tengo que seguir haciendo pruebas. Dejaré el hilo así interruptus..., pero si encuentro la solución volveré aquí y si no, también. Gracias