ACCESS - Bloquear nuevo registro si coinciden los 4 campos.
Tengo un pequeño problema. Estoy haciendo una base de datos de seguros.
Donde el pagador del seguro puede agregar a sus hijos, los cuales no tienen documento de identidad.
Así que puede darse el caso que se agreguen dos o más personas con los mismos nombres y apellidos. Con el documento de identidad vacío. Y para diferenciarlos que no se meta al mismo niño dos veces tener en cuenta la fecha de nacimiento.
Ahora mismo mi tabla tendría los siguientes campos.
id_asegurado, nombre, apellido 1, apellido 2, doc_identidad , fecha_nacimiento
Me gustaría que se pudiese meter por ejemplo estas filas.
Carlos Pérez Rodríguez No_doc_identidad 20/06/2019
Y puede que otro padre tenga otro hijo con el mismo nombre y mismos apellidos, pero claro nació en días distintos.
Carlos Pérez Rodríguez No_doc_identidad 29/08/2020
Entonces mi pregunta es. ¿Cómo puedo hacer para que en el formulario solo tenga en cuenta que si se pone el mismo nombre, apellidos y fecha nacimiento no te deje meter el registro y te avise que ya está registrado ese asegurado?
4 respuestas
¿Y quién dice que dos personas con el mismo nombre no puedan haber nacido también el mismo día? Aunque sea mucha casualidad, no es imposible.
Lo más correcto parecería comprobar que una persona no tenga 2 hijos que se llamen igual. Eso sí que no sería posible. Por tanto, no se trataría de impedir que se dieran de alta dos personas con el mismo nombre y fecha de nacimiento, sino dos personas dependientes del mismo asegurado (entendiendo que se trata del progenitor) y que se llamen igual.
Enrique Feijóo: creo que no ha leído mi respuesta con atención. Lo que yo digo es que puede suceder que dos personas que no tengan nada que ver se llamen igual y hayan nacido el mismo día. Aunque es casualidad, no es imposible. Y menos con nombres frecuentes. En cambio, lo mismo no sucederá con dos hermanos que, incluso naciendo el mismo día, seguro que no se llamarán igual. Por tanto, es más lógico vincular a los hijos con el parte (o madre) y simplificar la verificación de duplicados, puesto que no hará falta incluir la fecha de nacimiento. Basta con el progenitor y el nombre del hijo. Mucho más simple.
Por otra parte, añadir la hora, minutos y segundos a la fecha de nacimiento no tiene ningún sentido. Se la tendrían que inventar, por lo que la verificación de duplicados no realizaría esa función.
Enrique Feijóo:
"Poli Plos, en la línea de que es una probabilidad tan lejana o cercana como queramos considerarla, nada impide que dos gemelos se casen con dos gemelas y en la 'sincronia' que la sabiduría popular atribuye a las fases lunares, se diese el caso de que naciesen dos primos que pueden tener el mismo nombre, apellidos y fecha de nacimiento (la hora minuto y segundo ya seria para premio)."
Me parece que está usted complicando mucho la historia con gemelos, primos y fases lunares.
Sigue usted sin leer mi respuesta con atención. Lo que digo es que no va a haber dos hijos del mismo progenitor que se llamen igual. Por eso digo que lo mejor es vincular los hijos a sus progenitores y olvidarse de buscar duplicados por nombre y fecha de nacimiento, en general. Bastará con buscar los duplicados entre los hijos del progenitor, para lo cual bastará con el nombre.
Y lo de añadir la hora a la fecha de nacimiento está bien como ejercicio teórico. En la práctica, dígame usted cuántas aplicaciones conoce que soliciten ese dato al introducir la información de una persona. Y dígame de cuántas personas conoce usted esa información. Incluso de personas de su propia familia o de usted mismo.
No obstante, al margen de lo anterior, la comprobación de duplicados por el nombre es siempre un problema. No ya por posibles duplicados que en realidad no lo son, sino porque incluso los que sí lo serían, pueden pasar desapercibidos.
Ya se ha comentado el asunto de las tildes, pero con eso tampoco basta. Un mismo nombre se puede introducir de formas diferentes, de manera que parecen personas distintas. Por poner algún ejemplo, aunque creo que todos somos conscientes de que existen: "Mª José", "María José", "Mª. José", "M. José". Por no hablar de posibles errores tipográficos.
Las tablas de Access admiten crear índices, son algo similar a las llaves pero no son tan restrictivas como ellas.
Si se crea un índice con todos los campos que en conjunto han de ser únicos y se le indica que es 'sin repeticiones', solo dejara crear un único registro que las cumpla.
La validación la hará siempre al intentar guardar el registro, una forma de detectar si ya existe (antes de guardarlo y que de el error) es utilizando la función DCount en cuanto se disponga de los datos que componen el índice (si la cuenta es cero = False no existe, en cualquier otro caso la respuesta se considera un True).
--- INDICES, COMO CREARLOS -----
Con la tabla en modo diseño, activar la creación de índices (icono con el símbolo de un rayo)
.- Se le pone un nombre, y en la columna 'nombre del campo' el primer campo del índice.
.- A continuación el resto de campos (dejando en blanco el campo nombre del índice)
En la parte inferior teniendo seleccionada la línea con el nombre del índice, en sus propiedades:
.- Principal = NO (en otro caso seria una llave)
.- Única = Si (solo se admitirá un registro con esos datos, (la fecha puede ser la diferencia)
.- Omitir o no los nulos es optativo
Posiblemente (si ya hay algún campo indexado) aparecerá aquí (es un índice de un solo campo) se les respeta (o se les elimina si es/son innecesarios).
Como siempre:
No conviene abusar de los índices y mas si son compuestos pues han de verificarse con la manipulación de los registros (nuevos registros o cambios en ellos) y eso lleva su tiempo hacerlo bien.
Cualquier duda que aparezca publícala (es tan automático el crearlos, que a veces queda en el tintero algún detalle).
Poli Plos, es innegable que toda regla tiene su excepción, y también que a cada problema se le puede aplicar una solución.
En este caso (como se daría en el caso de partos múltiples) se le puede añadir el campo (hora + minutos + segundos) y ya existiría esa nimia diferencia.
Poli Plos, en la línea de que es una probabilidad tan lejana o cercana como queramos considerarla, nada impide que dos gemelos se casen con dos gemelas y en la 'sincronia' que la sabiduría popular atribuye a las fases lunares, se diese el caso de que naciesen dos primos que pueden tener el mismo nombre, apellidos y fecha de nacimiento (la hora minuto y segundo ya seria para premio).
Nada impide que en una familia todos los hijos compartan el nombre (sea como primero o segundo), al menos no recuerdo que exista una restricción a ese respecto o simplemente uno falleció y otro ocupa el espacio vacío.
Pero no deja de ser una excepción y como tal se ha de tratar, yo lo haría con un ID, mas fácil a la hora de asociar datos (solo se precisa uno que por definición es irrepetible).
En la historia de muchos (la mía por ejemplo) cuando al responder a una llamada telefónica le preguntaban si deseaba hablar con 'el padre o el hijo' la primer vez solían elegir al padre y a partir de de esa vez ya preguntaban directamente por el hijo (yo no cometí ese 'error', heredara defectos o virtudes pero no heredo 'el nombre')
Creo que tu aseguras a una persona en particular y que ésta puede tener ningún beneficiario, uno, dos,... Por tanto deberías tener una tabla con los datos del asegurado, por ejemplo, Idasegurado, nombre, dirección, DNI, etc. y luego otra tabla Beneficiarios. Con esos campos que citas. Por ejemplo, vamos a suponer que tengo un asegurado donde le he puesto un beneficiario. Lo que si es seguro, es que una persona no va a tener dos hijos( beneficiarios) con el mismo nombre, aunque le cambie las fechas de nacimiento
Vamos a suponer que repito un beneficiario, aunque le cambie la fecha de nacimiento. Puedes ver que el cursor aún está en el control FechaNac. Cuando pulso Enter
Es decir, me avisa de que ese beneficiario ya está dado de alta, y efectivamente, tiene en cuenta que puede haber dos asegurados que tengan un beneficiario con el mismo nombre y que incluso hayan nacido el mismo día. El código del evento Antes de actualizar del cuadro de texto Fecha es
Private Sub FechaNac_BeforeUpdate(Cancel As Integer)
If DCount("*", "beneficiarios", "nombre='" & Me.Nombre & "' and apellido1='" & Me.Apellido1 & "'and apellido2='" & Me.Apellido2 & "' and idasegurado=" & Me.IdAsegurado & "") >= 1 Then
MsgBox "De eso nada, ese beneficiario ya está dado de alta con ese asegurado", vbOKOnly + vbExclamation, "Lo siento, otro día será"
Cancel = True
End If
End SubLe he puesto lo de Cancel=true porque no sé que quieres hacer con el registro en caso de que se dé esa duplicidad, si quieres borrarlo, si cambiarer algún dato,...
No sirve el índice compuesto por el problema de los acentos. Comparto la respuesta de Julián, lo único que falta es validar los acentos, por ejemplo, García y Garcia si no se retiran los acentos va a permitir el ingreso del nuevo registro, para evitar esto complemento con este código:
Private Sub Form_BeforeUpdate(Cancel As Integer)
If DCount("*", "tblbeneficiarios", "strconv([nombre],2,1042)='" & StrConv(Me.nombre, 2, 1042) & _
"' and strconv([apellido1],2,1042)='" & StrConv(Me.apellido1, 2, 1042) & _
"'and strconv([apellido2],2,1042)='" & StrConv(Me.apellido2, 2, 1042) & "' and id_asegurado=" & Me.id_asegurado & "") >= 1 Then
MsgBox "El beneficiario ya está registrado", vbOKOnly + vbExclamation, "Le informo"
Cancel = True
End If
End SubIgualmente asumo que se trabaja con 2 tablas, tblasegurados y tblbeneficiarios relacionados por id_asegurado.
Tengo un software ganadero en donde en la misma tabla se registran los padres, madres e hijos y se valida no se repita el nombre de la cría, si utiliza 1 tabla, sería adaptarlo a sus caso.
Si quiere envíeme su base de datos a [email protected] y trato de adaptarlo con mi software.
Esta afirmación "Por eso digo que lo mejor es vincular los hijos a sus progenitores y olvidarse de buscar duplicados por nombre y fecha de nacimiento.." no es desde ningún tipo de vista la solución porque se puede repetir el nombre y demás datos, aunque es lógico un mismo padre no tendría 2 hijos con los mismos nombres. Ahora, respecto a ""Mª José", "María José", "Mª. José", "M. José" esto se puede validar e informar que ya existe al menos 1 hijo que el campo nombre exista y ¿Cómo? mediante LIKE. Porque se puede dar el caso de que un hijo se llame José Antonio y otro se llame María José, entonces, si es permisible el registro pero con el like podemos informarlo para que se reconsidere si es cierto. Lo de fecha, minutos y segundo es absurdo.
No luche el no acepta las observaciones de otros usuarios - Eduardo Pérez Fernández