FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Evitar Borrar un Registro
Se puede colocar alguna manera hacer que en una tabla Firebird que no se puedan eliminar Registro
Como una regla ? En un Trigger de Before Delete ? Gracia por sus aportes |
#2
|
||||
|
||||
Por supuesto, pero ¿que no se borre ninguno?
|
#3
|
|||
|
|||
Casimiro Notevi
Quiero evitar que por algún error de programa o un usuario borre un registro de una tabla determinada, pero ojo no del lado del programa quiero validarlo en la Base de Datos Imaginemos una tabla de artículos y por error el usuario le da al botón de eliminar o alguien con una herramienta como IbExpert tenga acceso a la BD e intente borrar un registro de esta tabla .... Quiero Blindar la BD para que no permita borrar ningun registro de esta tabla.. por supuesto que pueda controlar esta validación para que a futuro pueda activar o desactivar la misma Espero haber sido claro Gracias por el tiempo |
#4
|
||||
|
||||
Ya, vale, pero ¿cómo distingues los registros que pueden ser borrados y los que no?.
Mejor dicho, ¿cuándo vas a querer que se borren y cuándo no vas a querer?, ¿controlarlo en razón a qué criterios?, ¿permitir borrar los números pares?, ¿permitir borrar los lunes?, ¿añadir un campo para permitir borrar?, etc. En este caso no serviría de nada, porque si no puede borrarlo entonces va y modifica ese campo, borra el registro y vuelve a poner ese campo en "no permitir borrar". En fin, que creo que debes explicar con más detalle exactamente lo que quieres conseguir. |
#5
|
|||
|
|||
Cita:
No existe criterio,, simplemente después que se incluya un registro en esa tabla no se pueda borrar,, hasta que yo como el administrador de la base de datos quite esa validación o Regla. Gracia Casimiro por el tiempo |
#6
|
||||
|
||||
Puedes crear una exception, ejemplo:
Y luego un trigger en el BeforeDelete de la tabla:
Aunque si quieres permitir borrar entonces tendrás que desactivar el trigger. ¿Es eso lo que quieres? |
#7
|
||||
|
||||
Cita:
// Saludos |
#8
|
|||
|
|||
Cita:
El problema es que tengo un error con una aplicación determinada que esta permitiendo borrar registros de una tabla, mientras descubro el problema necesito temporalmente evitar que eliminen los registros. |
#9
|
|||
|
|||
Cita:
Gracias por el aporte |
#10
|
||||
|
||||
Cita:
Casimiro, ¿Firebird no permite prohibir por usuario acciones como el borrado de registros? Es que me parece curioso el método del trigger. En MySQL habría más bien pensado en restringir al usuario que se conecta quitándole el permiso de borrado sobre esa tabla. // Saludos |
#11
|
||||
|
||||
Sí, pero yo siempre uso el usuario sysdba y nunca he hecho ese control, debe ser fácil, pero tendría que mirar la documentación.
Además no creo que Efren2006 tenga usuarios distintos de sysdba ¿o sí? |
#12
|
|||
|
|||
Cita:
Casimiro Notevi La solución es Perfecta para lo que necesito.... Gracias nuevamente por el aporte Saludos |
#13
|
|||
|
|||
Efectivamente solo uso sysdba...
|
#14
|
||||
|
||||
Cita:
// Saludos |
#15
|
||||
|
||||
Debe ser eso, la "filosofía" de trabajo de cada uno. En firebird se suele usar solamente el usuario sysdba y si necesitas control por usuarios lo normal es crear una tabla para los mismos y controlarlo desde tu programa.
Incluso en el caso de varios programas que conectan a la misma base de datos también se sigue usando sysdba, siempre. Aunque por supuesto que se pueden crear usuarios en la base de datos y dar permisos, restringir, etc. por separado. |
#16
|
||||
|
||||
Ayer ya no pude contestar.
Puede ser filosofía, pero se me hace extraño. La tabla de usuarios es aparte. Es decir, cada sistema tiene su propia tabla de usuarios. Pero los usuarios del servidor dan una protección a bajo nivel, por decirlo de alguna forma. Por ejemplo, en el servidor del Club hay varios usuarios, muchos sin relación alguna uno con otro. Cada cual tiene su correspondiente usuario de MySQL y no puede tocar las bases de otro. Eso no quita que cada sistema, como este de los foros, tenga su propia tabla de usuarios para controlar el acceso a las funciones propias de los foros. // Saludos |
#17
|
||||
|
||||
Firebird se puede hacer mucho más seguro si se quitara la costumbre de utilizar únicamente SYSDBA. Lo más adecuado es agregar usuarios/roles para la bases de datos, donde cada uno tenga su propósito. Se le pueden dar permisos de escritura, lectura, o ambas... se le puede dar permisos para consultar e incluso se les puede restringir el acceso a nivel de campos.
Lo correcto es disponer SYSDBA como super-usuario o administrador como siempre, y luego agregar usuarios específicos para ciertos propósitos y de ese modo uno puede controlar mejor ciertas cosas... por ejemplo un usuario diseñado para un simple operador de caja no debería poder contar con acceso a las cuentas contables de la empresa o ver quien de sus compañeros gana más. El tema es que una cosa es usuarios a nivel de aplicación, que es cuando uno agrega tabla de usuarios en sus bases de datos, y otra son los usuarios de base de datos. Firebird cuenta con un nuevo conjunto de tablas de sistema pensando para monitoreo MON$ que amplía y complementa a RBD$. Pero de nada sirve intentar monitorear lo que va sucediendo si ve por ejemplo 20 usuarios SYSDBA conectados a la base, así uno no puede distinguir quien es quien realmente... por más que lo acompañe de la IP desde donde están conectados. Ahora uno tiene que adivinar, o tener a mano una hoja con el relevamiento de todos los miembros de la empresa, a que máquina pertenecen, su IP, etc. Por eso es que uno se inclina a disponer de tabla de usuarios junto con tablas de log o bitácora a modo de auditoría. Lo de trabajar únicamente con SYSDBA es un mal que hay que empezar a erradicar. ¡Y lo dice alguien que también solo usa SYSDBA! Lo que no recuerdo es si existe algún límite y restricciones sobre la cantidad de roles/usuarios y funciones. Saludos, |
#18
|
|||
|
|||
Permisos en Firebird ...
Totalmente de acuerdo con Delphius. En mi humilde opinión, Firebird tiene una mejor implementación de manejo de permiso que MySQL (y que algunas otras base de datos). Tratándose por ejemplo de permisos de escritura en una tabla, puedes incluso, dar permisos por campo. Es decir, si una tabla tiene los siguientes campos: Field1, Field2, Field3. Puedes otorgar permiso a un usuario para que solo Field1 y Field2 sean de lectura, y Field3 sea de lectura y escritura.
Otra cosa, puedes incluso otorgar permisos a las disparadores de las tablas para que ejecuten procedimientos almacenados (te ahorra sobre todo trabajo, al no tener que dar específicamente permisos de ejecución sobre dicho procedimiento a cada usuario). Por alguna razón que aun no entiendo, son pocos los programadores que hacen uso extensivo del manejo de permisos y roles en Firebird (créanme que es una herramienta sumamente poderosa y te quita de muchos problemas de encima si se sabe utilizar correctamente). También al que reconocer que esto le agrega un nivel más de complejidad. Finalmente, la solución al problema de Efren2006 se puede solucionar con permisos (como lo plantea Román) o con un disparador (como ya bien lo dijo Casimiro). Lo único que yo le agregaría al disparador que propuso Casimiro Notevi es una condición para checar si el usuario conectado (curren_user) es el administrador o si tiene un rol de administrador. Con esto quito la necesidad de estar habilitando/Deshabilitando el disparador (lo cual no resulta ser muy seguro, por obvias razones). Saludos, Gerardo Suárez Trejo |
#19
|
||||
|
||||
Estoy de cuerdo contigo (y con Delphius), aunque he de decir que MySQL tambien maneja permisos a nivel de campo y lo hace desde hace mucho tiempo. Lo de los triggers no lo creo y de hecho, los procedimientos almacenados de mysql son inusables en la práctica pues tiene un rendimiento muy malo.
// Saludos |
#20
|
|||
|
|||
Aunque pueda estar de acuerdo en los planteamientos de utilizar distintos usuarios y no sysdba, en mi caso me pareció mas practico porque yo tengo varios clientes que utilizan mi sistema y la estructura de la base de datos es igual para todos, entonces cuando le hago modificaciones a la base de datos tengo un programa que sincroniza la base de datos antigua a la nueva, si utilizara usuarios particulares para cada cliente, tendría que rehacer o guardar todos los usuarios, de esa forma me pareció mas cómodo y menos problemático, adicional que la gran mayoría de los clientes soy yo el que administra la BD.. En fin,,,
Gracias todos por sus aportes |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Trigger - evitar borrado de registro | StartKill | MySQL | 1 | 04-03-2008 14:49:24 |
Evitar el agregar registro en una DbCtrlGrid | Manuel | Varios | 4 | 27-11-2006 19:22:45 |
Como Evitar Borrar Registro en dbGrid al Presionar ESCAPE ???? | AGAG4 | Varios | 4 | 07-07-2006 04:30:20 |
Evitar Borrar más filas con DBGRID | User_Baja_2 | Varios | 4 | 12-01-2006 23:59:09 |
Borrar lineas detalle al borrar registro maestro | akinom38 | Conexión con bases de datos | 3 | 11-01-2006 10:38:07 |
|