Registros no actualizados. Saber cuáles

[cmarti]

Cómo hago para saber durante un proceso de actualización, qué (no cuántos) registros no fueron actualizados?
Pd.: Se me ocurre crear una tabla llamada (p. ej.) "reg_noact" y que por cada registro no actualizado me mande su id a "esa tabla". Está bien o es una locura?

Gs

[Heimish2000]

Es una locura. Para eso pones un campo "ACTUALIZADO" en tu tabla, por defecto a cero, y cuando lo actualices lo pones a uno. Los que tengan el cero son los que no se han actualizado.

Pero basta con utilizar el WHERE que utilices para hacer el UPDATE en una SELECT y sabrás que registros se actualizan, el resto de los de la tabla son los que NO se actualizan.

[javiDP]

Tambien puedes crearte un trigger, que despues de hacer un update, por cada fila(for each row), te inserte el id de la fila actualizada en una tabla de logs que tenga solo un campo id. Despues lo unico que tendrias que hacer es esto:

Código MySQL:

select * from nombre_tabla_actualizada where id NOT IN(select id from log_updates);
 

Asi te devolveria todas las filas que no han sido actualizadas. Una vez sacadas, debes acordarte de vaciar la tabla de logs con un delete from log_updates; para que no te de fallos la proxima vez que quieras consultar las filas que no se actualizaron de una tabla.


Con la forma que te ha expuesto heimish tambien se puede hacer...pero tendrias que crear un campo "ACTUALIZADO" en todas las tablas que quieras comprobar, y ademas, aparte de poner ACTUALIZADO a 1 en las que esten actualizadas, deberias poner 0 en las que no se actualizaron, porque si no a la siguiente consulta puede haber filas que actualizaste antes pero ahora no y te de como que estan actualizadas. Evidentemente esta forma es menos eficiente, mas lenta (debes cambiar ACTUALIZADO en todos los registros) y consume mas tamaño en disco.

Yo lo haria como te he expuesto mas arriba, que te sirve para cualquier tabla sin tener que modificar nada dentro de ella, solo crear tantos triggers como tablas quieras comprobar . Un saludo!

[cmarti]

Lo voy a explicar de otra manera.

De 30 campos que componen la tabla a actualizar, entre 10 a 15 de ellos indistintamente, se irán actualizando. No será siempre el mismo tipo de actualización porque si fuera así con poner un check o un campo booleano listo. No es ese el caso.

Supongamos que voy a ejecutar una 2da corrida donde se actualizarán los reg: 1, 3, 7 y 10 (los reg. 2,4,5,6,8 y 9 ya fueron actualizados sobre otros campos distintos en la 1er corrida).

Necesito que durante la úlitma actualización me informe solamente si el 1,3,7 y 10 fueron actualizados.

Tengo objetos que van cambiando de estado. Si yo agrego a la tabla un campo que me diga actualizado o no, no me sirve porque lo que realmente quiero saber es si en la ultima actualización se les agregó el nuevo estado. Se imaginan que no voy a poner Select * from .... where estado = 'bla bla bla'. No termino más porque como decía más arriba, son muchos campos y con diferentes valores que van tomando a lo largo de su ciclo de vida.

Lo que se me ocurre y concuerdo con XXXXX es que si el registro no se actualiza, me mande a una tabla log o "reg_noact", los id de los que tuvieron problemas.

Como el material original está en un excel que es el que maneja el usuario y el nro de no actualizaciones es bajo, en esta 1era etapa solo le mandaré los nros de ids que tuvieron problemas.

La idea, en un futuro INMEDIATO, es generar un excel de salida únicamente con los registros problemáticos para ser corregidos.

Mandarle actualmente un listado de registros con problemas (solo eso) me sirve de backup para ver sobre qué registros actuó el cliente.

Espero se entienda

[Heimish2000]

Iniciado por cmarti

Lo voy a explicar de otra manera.

Tengo objetos que van cambiando de estado. Si yo agrego a la tabla un campo que me diga actualizado o no, no me sirve porque lo que realmente quiero saber es si en la ultima actualización se les agregó el nuevo estado.

Si te sirve si justo antes de hacer la actualización pones ese campo para todos los registros a NO ACTUALIZADO (o a cero o al convenio que tu quieras tener en ese campo)

Otra opción es poner la fecha y hora de la última modificación del registro y luego filtrar por ese campo.

[gnzsoloyo]

En esencia, lo que planteas es crear un sistema de auditoría sobre tu base, cosa que como no es parte de los recursos de MySQL, tendrás que crear por tí mismo y para tu propósito. No veo otras soluciones.
Algunos de los detalles que hay que tener en cuenta para poder diseñarlo son:
- Cada ejecución de una consulta de INSET/UPDATE/DELETE sobre una tabla y un registro devuelve una cantidad de registros afectados iguala 1. Pero no devuelve qué campos se afectaron en esa consulta.
- Una consulta de INSET/UPDATE/DELETE de múltiples registros nos informa la cantidad de registros afectadas, pero no permite establecer qué registros fueron los afectados, por lo cual solamente un INSET/UPDATE/DELETE individual serviría para una auditoría.
- El único modo de capturar la acción de modificación de registros por medio de INSET/UPDATE/DELETE sería usando TRIGGERS, siemrpe y cuando no haya TRIGGERS definidos para esos eventos en las tablas, caso en el cual la auditoría debería estar integrada a los mismos.
- Aún cuando se pudiese hacer por TRIGGERs, eso implicaría definir TRIGGERs para cada tabla. Huelga decir que eso impactará en la performance negativamente.
- Si los valores a cambiar no son siempre los mismos, habría que registrar los dos estados, porque no hay forma de hacer un TRIGGER que "adivine", a priori cuál es el valro que está ingresando, y además no puedes recorrer la estructura de la tabla que estás modificando, al menos no en MySQL. En otras palabras, INSET/UPDATE/DELETE dinámicos no se pueden adminsitrar fácilmente con TRIGGERS, por lo que solamente podrías intentarlo con stored procedures, con la limitación de que en un SP no hay parámetros opcionales, por lo que deberías enviar todos y resolver la inserción/actualización en forma dinámica por dentro del SP... lo que sería demasiado complicado.
- Por otro lado, que un registro no sea afectado no implica que haya un error (que de por sí es un evento detectable), sino por otras causas como por ejemplo que el valor ya exista en la tabla y en ese campo, o porque el registro buscado no existe; ninguna de las dos son errores desde ese punto de vista.

En definitiva, lo que yo considero viable es crear una tabla de auditoría donde se pueda almacenar, a través de la aplicación, los parámetros enviados a la consulta en aquellos casos en que la consulta modifique registros, de modo de poder revisarlos como tabla. Lo que veo difícil es el modo de hacer una consulta que te devuelva exactamente qué campos no fueron afectados en un registro dado, o si el registro no fue afectado porque no había cambios que debieran hacerse.

[cmarti]

Heimish2000. Lamentablemente no me sirve porque como te digo, un campo el mismo día puede sufrir más de una actualización. Lo de fecha como decía antes no es una mala idea pero tengo que tener presente la hora de esos arreglos. Se me ocurre que lo mejor es tener una tabla de "pdtes" y cuando un registro no se actualice me complete esa tabla para saber el por qué.

Gs. de todos modosl.

[Heimish2000]

Fecha y hora, un TIMESTAMP.

De todas formas, ya te lo dije, un campo que se actualice en toda la tabla antes de actualizar y que se actualice luego unicamente en los registros que quieres. O más sencillo, un campo que indique el número de la última actualización en la que se ha visto afectado y tener una tabla con un campo que sea número de actualización, cada vez que actualices, sumas uno al número de actualización y luego con el número que tengas guardado actualizas el campo nuevo.

Hay muchas alternativas y, para mi, mejores a crear una tabla nueva.

[cmarti]

amigo y para ir cerrando. A mí el nro de actualización no me importa. Lo que a mi me importa es que al momento de actualizar como corresponde se actualiza.
Te doy un ejemplo.

Supongamos que tengo un campo llamado color: En la primera actualización no tiene nada, en la 2da recibe el string "azul", en la 3er actualización no recibe nada por lo tanto, sigue con el valor azul. En la 4ta recibe "blanco". A mi no me importa si ése campo era null o tenía algún dato (siguiendo el ejemplo "azul"). A mi lo que realmente me interesa es que en la 4ta actualización reciba "blanco".

Espero se entienda. Gs

[gnzsoloyo]

Si luego del UPDATE, la función ROWS_COUNT() devuelve 1, es que se actualizó, si devuelve 0 no lo hizo.
Haz una tabla nueva donde guardes la consulta enviada por cada valor > 0 devuelto por ROWS_COUNT(), o bien cualquier valor mayor a cero devuelto por mysql_affected_rows() si usas PHP, inmediatamente después de la ejecución.
En cualquier caso, lo deberás manejar coordinadamente entre la aplicación y la base. No puedes hacerlo sólo por la base de datos.

[Heimish2000]

Iniciado por cmarti

amigo y para ir cerrando. A mí el nro de actualización no me importa. Lo que a mi me importa es que al momento de actualizar como corresponde se actualiza.
Te doy un ejemplo.

Supongamos que tengo un campo llamado color: En la primera actualización no tiene nada, en la 2da recibe el string "azul", en la 3er actualización no recibe nada por lo tanto, sigue con el valor azul. En la 4ta recibe "blanco". A mi no me importa si ése campo era null o tenía algún dato (siguiendo el ejemplo "azul"). A mi lo que realmente me interesa es que en la 4ta actualización reciba "blanco".

Espero se entienda. Gs

En ese ejemplo, sabrás si se ha actualizado si en el campo nuevo hay un 4 y sabrás que no se ha actualizado si hay otra cosa. Es facil

Pero bueno, yo simplemente te he planteado varias soluciones a tu pregunta en el foro, ya luego cómo lo hagas es cosa tuya.

[cmarti]

Muchachos. Gracias a todos por la ayuda. Como Uds. saben, en programación la salida debe ser una pero el código puede ser variado. De las ideas que me han comentado la que más me conviene por lo menos por el momento, es la que menciona javiDP dado que lamentablemente mi HSP (Dattatec) no me deja correr Store Procedures, ni tiggers (esto último casi seguro que no) por lo cual, la única manera de actualizar datos es finiquitándolos en local y subir los updates correctos es decir, si tengo algún problema verlo en local y no en remoto.
El sistema sigue siendo un dolor de cabeza pero bueno, veré como va la cosa. Si no me equicovo el tema de los tiggers y los Store Procedures en los HSP es cosa prohibida. En gral, dan una herramienta administrativa (phpmyadmin por ej.) para poder levantar archivos .sql, etc. es por ello que debo tener todo listo antes de la actualización.
Bueno gs. de nuevo y si surjen novedades les cuento.