Un problema originado por la Integridad Referencial

232 views
Skip to first unread message

Fox Learner

unread,
Jul 6, 2012, 10:25:20 AM7/6/12
to publice...@googlegroups.com
Compañeros,

En el trabajo tenemos un sistema en VB con un modulo .NET que envia datos a un dominio web.

El asunto es que cuando se crea un usuario y ese usuario genera transacciones, después cuando se quiere borrarlo dice que no se puede porque existen operaciones relacionadas.

Tengo curiosidad de saber como se solucionaría eso ya que no deseo que me pase lo mismo en alguna aplicacion de Visual Foxpro.

Considero un error grave no "poder borrar" un usuario ya que dicho usuario podría entrar al sistema cuando tenga la menor oportunidad y modificar datos de lo que le permita su "perfil" de usuario.

Si me expliqué?...

Saludos!

Bruno Xamarin

unread,
Jul 6, 2012, 10:28:50 AM7/6/12
to publice...@googlegroups.com
Código...
--
<!-- www.xamarin.com -->
namespace Xamarin
     {     Register( "Build_Cross_Platform_Mobile_Apps_using_C#_and_.NET");     }




Fox Learner

unread,
Jul 6, 2012, 10:32:09 AM7/6/12
to publice...@googlegroups.com
Ahi está el error en el adjunto. Saludos!
IR Error.JPG

Richard Gaviria

unread,
Jul 6, 2012, 10:33:51 AM7/6/12
to publice...@googlegroups.com
Esto en realidad no es un error es una protección que te ofrece la base de datos cuando una clave primaria es utilizada como clave foránea en otra tabla es para garantizar que no se va eliminar un registro que contenga la referencia de otra tabla.

Saludos

Rick.



Date: Fri, 6 Jul 2012 07:32:09 -0700
From: thenewin...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Re: Un problema originado por la Integridad Referencial

mpulla

unread,
Jul 6, 2012, 10:37:30 AM7/6/12
to publice...@googlegroups.com

Hola Fox Learner.

Un error grave seria dejear que borres un resgistro relacionado, para eso esta la integridad referencial para evitar esos errores..

Inactiva al usuario para que no pueda ingresar al sistema.

Saludos.
Mauricio

Domingo Cuevas

unread,
Jul 6, 2012, 10:37:49 AM7/6/12
to publice...@googlegroups.com

Antes de eliminar el Usuario debes deshabilitar o eliminar el foreign key hacias las tablas que lo tenga y luego habilitar o crear de nuevo el foreign key. Cuando en una base de datos se trabaja con Integridad Referencial hay que tener un buen diseño de la misma que contemple ese tipo de acciones, en algunos casos lo que se hace es deshabilitar ese registro (Usuario) y en los querys no toma estos registro en cuenta.

 

 

Saludos,

Fox Learner

unread,
Jul 6, 2012, 10:40:54 AM7/6/12
to publice...@googlegroups.com
No tengo acceso al "codigo" porque es un sistema que manejamos pero obvio que no lo hice yo jeje

No se hacer casi nada de Vb 6 aunque puedo "leer" gran parte de los codigos fuente al verlos. Vb era un lenguaje "intuitivo".

Pero aun así quisiera saber como se soluciona eso en Visual Foxpro..

Saludos!

Luis Mata

unread,
Jul 6, 2012, 10:39:39 AM7/6/12
to publice...@googlegroups.com
lo hermoso de la integridad referencial, es es lo que me sedujo.. No es error te esta cuidando los datos...............
 
Sent: Friday, July 06, 2012 9:32 AM

Luis Mata

unread,
Jul 6, 2012, 10:43:32 AM7/6/12
to publice...@googlegroups.com
QUEEEEEEEEEEEEEEEEEEEE!!!!!!!!!!! Aconsejas romper la seguridad de la Base de Datos? que mal!!!!

Fox Learner

unread,
Jul 6, 2012, 10:46:40 AM7/6/12
to publice...@googlegroups.com
Oooookkkkkkkk! Ya entendí. Entonces hay que "inabilitar el usuario" de alguna forma y tambien en los querys.

Entonces, según lo percibo, esto es un grave "error de seguridad" porque no ninguna forma de inhabilitar al usuario aun usando la clave de administrador del sistema.

Concluyo que el único que podría borrar los usuarios que ya no utilizan el sistema sería el DBA.

Porque los desarrolladores ya no están disponibles. Ni modos, se les pasó preveer esa situacion.

Saludos!

Luis Mata

unread,
Jul 6, 2012, 10:44:46 AM7/6/12
to publice...@googlegroups.com
Lo registros Jamás deberían de eliminarse físicamente solo deberían de cambiar de estado: ACTIVO a INACTIVO, eliminar un usuario que tiene historial de transacciones seria el mas grave error de tu parte ya que dejarías huérfanos varios registros.

Luis Mata

unread,
Jul 6, 2012, 10:53:54 AM7/6/12
to publice...@googlegroups.com
Dale con eso, No se debe de eliminar físicamente nada, solo cambiarle de estado Inhabilitarlo. Eso se llama integridad referencial.
 
Mira esto es sencillo pero claro:
 
La integridad referencial protege la información de los usuarios y de ti mismo.
 
Ejm:
 
- Si quieres eliminar la cabecera de una transacción, no te dejara por que tiene detalles. Primero debes de eliminar los detalles luego la cabecera.
- Si quieres eliminar un Usuario y este tiene ventas asociadas, no podrás porque la BD te dirá que tiene ventas asociadas y que primero debes quitar las ventas y luego al usuario.
- si quieres eliminar un articulo (GRAVE) y este tiene proformas, te dirá que no puedes hacerlo.
- si por algún error la cabecera de una factura no se guardo, será imposible que puedas guardar el detalle.
 
La integridad referencial es un tema de orden, de jerarquía de datos, Papa, hijo, nieto, bisnieto.........
 
Ahora si no tienes integridad referencial, todo lo anterior podrás hacerlo a diestra y siniestra.... al final la información va a quedar hecho basura.........
 
Sent: Friday, July 06, 2012 9:46 AM

Fox Learner

unread,
Jul 6, 2012, 10:57:13 AM7/6/12
to publice...@googlegroups.com
Y no existe algo como el "marcado para borrado" (Delete) en los SGBD para evitar la fatiga de andar poniendo un campo de activo/inactivo?..

Disculpen la ignorancia..

smartito

unread,
Jul 6, 2012, 10:57:14 AM7/6/12
to publice...@googlegroups.com
Te pongo un ejemplo

Tabla Madre CabeceraFacturas
Tabla Hija DetalleFacturas

Ambas relacionadas por IDFACTURA

Si no existiera la Integridad Referencial y permitieras borrar filas de la tabla Madre, sin tener en cuenta la tabla Hija, tendrías registros Huérfanos en la tabla Hija (sin madre puesto que las has borrado) ...

Pues con los usuarios y sus "movimientos" igual, :D

Es una norma básica de el diseño y modelado de las bases de datos.
Saludos!

WarpaRuna

unread,
Jul 6, 2012, 11:27:44 AM7/6/12
to publice...@googlegroups.com
Es cierto que la integridad referencial a uno le protege, incluso de uno mismo. Porque al menos cuando empieza a programar como novato, y con facilidad que nos da foxpro, con el browse, a uno se le antoja querer eliminar registros que se consideran inutiles. 
Si uno no quiere eso, hay que programar sin eso, sin la integridad, pero la verdad, hay que armar un sistema bien elaborado, ya que las tables que tienen esa relaiuon madre - hija, si se eliminan registros en la madre, friega todo, o que se duplica un registro madre, porque no hay un control estricto sobre la numeración, se arma un enredo terrible.

Claro en el caso del usuario, la logica es inhabilitarlo, y ya no podra hacer ninguna operación, y mas bien quedará el registro histórico de su periodo en que estuvo y lo que hizo estando activo, y que en algun momento podria interesar verlo. Tiene razón el maestro Mata




Luis Maria Guayan

unread,
Jul 6, 2012, 11:48:40 AM7/6/12
to publice...@googlegroups.com
Creo que tu tienes error de conceptos. La integridad referencial es así, no es un error, el error sería que se borre un usuario y queden registros "colgados"

Al registro del usuario solo se lo debe inhabilitar o cambiarle las credenciales de inicio del sistema.

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

Fox Learner

unread,
Jul 6, 2012, 12:02:36 PM7/6/12
to publice...@googlegroups.com
Gracias por las clases de IR jeje

Hasta la fecha no uso nada de eso..

Repito (como en los foros técnicos de MS y otros que te ponen lo mismo vez tras vez. Andan bien roboticos esos tipos jeje):

Walter R. Ojeda Valiente

unread,
Jul 6, 2012, 3:33:39 PM7/6/12
to publice...@googlegroups.com
Y está muy bien, no hay que borrar al usuario que realizó alguna operación, eso es lo correcto. Porque si lo borras sus operaciones quedarían "huérfanas". Tienes un error de concepto allí queriendo borrar a un usuario que ya realizó operaciones.

¿Solución?

Tener una columna (campo) en la tabla de usuarios que te indique si está activo o no. Inclusive si quieres mejorarlo puedes establecer los días y las horas en las cuales dicho usuario puede conectarse a la Base de Datos, por ejemplo:
Lunes de 7:00 a 19:00
Sábado de 7:00 a 13:00

También puedes tener un contador de las veces que se conectó, un contador de las veces que salió "impropiamente" del sistema, etc.

Saludos.

Walter.





Date: Fri, 6 Jul 2012 07:25:20 -0700
From: thenewin...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Un problema originado por la Integridad Referencial

Samuel San Miguel Hernández

unread,
Jul 6, 2012, 3:51:37 PM7/6/12
to publice...@googlegroups.com
Asi es, la Integridad Referencial es lo fundamental para una buena Integridad de información en tu BASE DE DATOS, es lo mejor para el manejo y actualizacion de información relacional:
se recomienda para UPDATE = cascada ; para INSERT y DELETE  restringir.

Ahora si deseas que el usuario no logee; simplemente inhabilitalo, denegar permiso a las opciones del menu, o cambiale la clave por si alguna vez pretende ingresar u oro usuario antiguo desea ingresar con ese usuario. Si no manejas el campo ESTADO, entonces create una tabla secundaria y ahi ingresa todos los que cesan, luego te creas un QUERY cruzas la tabla principal de usuarios Vs la tabla secundaria creada, los que no estan ahi , esas nada mas se deben ver ó elegir al momento de logear.

Saludos.




El viernes, 6 de julio de 2012 14:33:39 UTC-5, Walter R. Ojeda Valiente escribió:
Y está muy bien, no hay que borrar al usuario que realizó alguna operación, eso es lo correcto. Porque si lo borras sus operaciones quedarían "huérfanas". Tienes un error de concepto allí queriendo borrar a un usuario que ya realizó operaciones.

¿Solución?

Tener una columna (campo) en la tabla de usuarios que te indique si está activo o no. Inclusive si quieres mejorarlo puedes establecer los días y las horas en las cuales dicho usuario puede conectarse a la Base de Datos, por ejemplo:
Lunes de 7:00 a 19:00
Sábado de 7:00 a 13:00

También puedes tener un contador de las veces que se conectó, un contador de las veces que salió "impropiamente" del sistema, etc.

Saludos.

Walter.





Date: Fri, 6 Jul 2012 07:25:20 -0700
From: thenewin...@gmail.com

Fox Learner

unread,
Jul 7, 2012, 3:47:01 PM7/7/12
to publice...@googlegroups.com
Ok. Entonces asumo por sus comentarios que no existe una forma de "marcar para borrado" en los SGDB (DELETE) ya que el delete realmente borra y empaca los registros segun me dan a entender.

Saludos!

Walter R. Ojeda Valiente

unread,
Jul 7, 2012, 4:05:43 PM7/7/12
to publice...@googlegroups.com
Ciertamente, pero con matices.

Al menos en Firebird cuando borras una fila ella no es eliminada físicamente de la Base de Datos hasta que se ejecute un proceso llamado "recolección de basura", el cual se puede configurar cada cuanto se hace, hacerlo manualmente cuando se desea, o hacerlo automáticamente cada vez que se realiza un backup.

De todas maneras, como creo que fue el consejo unánime, lo aconsejable es que NO ELIMINES fisicamente las filas sino que les coloques una marca que te indique si está ACTIVA o INACTIVA. Y si quieres mejorarlo, puedes indicar también quien la inactivó, la fecha, la hora, etc.

Saludos.

Walter.





Date: Sat, 7 Jul 2012 12:47:01 -0700
From: thenewin...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Re: Un problema originado por la Integridad Referencial

Fox Learner

unread,
Jul 7, 2012, 7:06:38 PM7/7/12
to publice...@googlegroups.com
Ok. Me declaro "bienvenido" al nuevo mundo de los SGBD. Ni modos a cambiar el "chip" jeje

Gracias y Saludos a todos los "Masters de Visual Foxpro"!

Luis Mata

unread,
Jul 9, 2012, 10:11:13 AM7/9/12
to publice...@googlegroups.com
Bienvenido....
 
Sent: Saturday, July 07, 2012 6:06 PM
Subject: [vfp] Re: Un problema originado por la Integridad Referencial
 
Reply all
Reply to author
Forward
0 new messages