23 respuestas en este tema

[luk2009]

Hola a todos

De cara al usuario que cosas se deben tener el cuenta para crear un formulario donde sea facil entrar los datos, que no se repitan registros y demas. 

Tips, ideas, trucos para el formulario.

Digan algo, no les de verguenza, que a mi no me dió verguenza preguntar.

[razadi]

Saludos luk2009, pues yo lo primero que haría sería ver exactamente de que voy a hacer el formulario, es decir un formulario para la captura de un empleado o un formulario para introducir datos para una factura, etc.

Después, trataría de ponerlo de una manera que al usuario le sea fácil leer, cero florecitas, algo agradable pero que NO lo distraiga.

Seguimos con datos concretos, que NO se le pregunte algo que sea obvio, algo redundante, algo que sea difícil de responder.

Luego ponerle ayudas, para que le sea más fácil escribir sin teclear tanto, como por ejemplos (Ayudas con un shortcut, algún combo, etc.), recuerda que los usuarios son una especie que hay nanita, creen que todo lo saben y no hacen lo que deben hacer.

mmm, creo que para mi con esto es más que suficiente para poder hacer un buen formulario.

Espero te sirva, saludos.

[enecumene]

Yo coincido plenamente con lo que comenta el amigo razadi .

Saludos.

[luk2009]

Gracias Razadi por tu respuesta. Mi problema es que cuando el usuario vaya a registar un nuevo cliente este no este ya dentro. El problema viene porque puede haber dos personas que tengan el mismo nombre y el mismo apellido. Lo que habia hecho era poner un edit y un boton y un dblookupcombobox. La idea es que el usuario entre el nombre del cliente o la direccion y aparezca en el dblookupcombobox los que coincidan. Si no hay coincidencias entonces se le pregunta si quiere crearlo. En caso de que exista se activa el boton de modificar.

Que piensan de esto.

[enecumene]

mmm, yo lo hago de esta manera, al momento de guardar realizar un query verificando si existe o no ese cliente, en caso de existir lance un aviso en caso contrario lo guarde.

Saludos.

[egostar]

En este caso, creo que deberías de hacer un filtro sobre la empresa, puede haber "n" clientes con el mismo nombre, pero solo una compañia.

Salud OS

[poliburro]

Gracias Razadi por tu respuesta. Mi problema es que cuando el usuario vaya a registar un nuevo cliente este no este ya dentro. El problema viene porque puede haber dos personas que tengan el mismo nombre y el mismo apellido. Lo que habia hecho era poner un edit y un boton y un dblookupcombobox. La idea es que el usuario entre el nombre del cliente o la direccion y aparezca en el dblookupcombobox los que coincidan. Si no hay coincidencias entonces se le pregunta si quiere crearlo. En caso de que exista se activa el boton de modificar.

Que piensan de esto.

Tu solución es correcta, pero tiene la desventaja que agregas carga a tu base de datos. Lo que puedes hacer en su lugar es que antes de grabar consultes si existe el cliente si no, lo crea si existe avisa de ello.

saludos

[luk2009]

Gracias por sus respuestas

El problema es que muchos de los clientes son personas no empresas. Esto provoca que pueda haber dos o mas personas con igual nombre y apellido. La idea es que ya que sabes que hay dos o mas Juan Perez, puedas recorrerlos y verificar que no sea ninguno de los que esta ahi. Si descubres que es uno nuevo entonces le das al boton de crear y entras los datos correspondientes al cliente nuevo.

La idea es permitir al usuario que al entrar el nombre. el telefono o la direccion, vea cuales coinciden y si ya existe pueda modificar cualquier dato, si es necesario.

[enecumene]

Pues amigo, con lo que hemos comentado el poli y yo es tu solución natural, sólo debes elegir el dato a comparar .

Saludos.

[luk2009]

Gracias Enecumene, Lo que pasa es que no tiene sentido que haga la comparacion despues de haber entrado los datos
ejemplo: escribo nombre, direccion, telefono, referencias de la direccion, tipo de equipo y otros y luego le doy a guardar y hago un query. Si existen varios y uno de esos es el que estoy duplicando, Ya habria trabajado para nada.

La idea es hacer la verificacion antes con un query que llena el dblookupcombobox y me muestra los similares y asi se
puede establecer si existe o no y luego procedo a entrar los datos del nuevo cliente.

[Fenareth]

Pues la idea de hacer una pre-búsqueda mediante una consulta no suena mal, sólo que en vez de un Dblookupcombobox yo lo mostraría mejor en un DBGrid, me parece más sencillo de visualizar TODAS las coincidencias al mismo tiempo y así ver si una es la que ando buscando, en caso contrario, dar de alta a mi cliente nuevo...

Así es como lo visualizo yop :$

Saludox !

[luk2009]

Gracias Fena por la respuesta y perdon por la confianza. Esa fue mi primera idea, pero lo que hago es que si se encuentran
coincidencias se envie el foco al dblookupcombobox y con solo mover la flechas el usuario puede ver en el mismo formulario de entrada de datos, todas las informaciones del cliente en cuestion y puedo mostrar mas datos.

[Delphius]

Yo quisiera hacer una preguntita: ¿Se ingresa alguna clave artificial o dato de las personas que podría ser candidato a clave primaria? Voy a citar un ejemplo: el número de DNI o Documento Nacionalidad de Identidad. Podrán haber dos o más Juan Pérez pero si hay algo que los distingue es que poseen distintos DNI.

Obviando el hecho de los DNI trucos y falsificados o los robos de identidad... el DNI es un buen candidato a ser clave primaria.

Si existe esta clave primaria no hay necesidad alguna de estar lanzando una pre-consulta para saber si existe. Simplemente se manda la instrucción SQL INSERT con el DNI como clave... si por algún descuido o error de dedo se intentase registrar una persona con igual DNI el motor protestará arrojando una excepción o error informando de que la clave fue duplicada. Por tanto, da a entender que se está intentando guardar un registro ya existente.

Si el DNI fuese otro, no importa el nombre... el motor solito se encargará de saber y poder identificar a cada Juan Pérez que encuentre

¿Me explico?

Saludos,

[luk2009]

Gracias Delphius por tu respuesta.

Vamos a aclarar el asunto. Los clientes son los de una empresa que instala sistemas de alarmas. El numero de cuenta, la cual es la clave primaria, es el numero que envia el sistema de alarmas a un aparato.

Delphius tienes razon, nunca se va a repetir la clave primaria, pero si se puede dar el error de que alguien registre de nuevo a Juan Perez, que ya esta registrado con otro numero de cuenta. Por esta razon hace falta saber si ese numero de cuenta ya esta siendo usado o si ese nombre esta siendo utilizado en alguna cuenta.

Esta base de datos se maneja poniendo una I  delante de los clientes que se han retirado por alguna razon o que solo estan registrados pero no envian datos a la empresa. Por eso el numero de esos clientes retirados esta disponible nuevamente.

Ejemplo el cliente  0500 se retira y ese numero se le asigna a otro cliente. Cuando vas a introducir un nuevo cliente es bueno consultar si ese numero se esta utilizando o no.

[glow=red,2,300]Creo que la explicacion complica mas todo, pero que puedo hacer, le estoy respondiendo a delphius con su estilo
[/glow]

[Delphius]

Gracias por las aclaraciones luk2009,

Entonces me callo :-#
Se necesita de pre-consultas entonces.

El escenario que yo describí es el hipotético y general. Lo tuyo más que nada sería una excepción a la regla.

Si me lo permiten... ¡que ganas de complicarse la vidas con ese sistema de numeración de cuenta!

Saludos,

[JoAnCa]

Pues coincido con delphius, lo unico mas aceptable que se me ocurre es usar una llave primaria, y del resto se encarga el propio motor de la BD, y tu no tienes que programar nada para saber si existe ya.

El número de identificacion personal es único para cada persona (ya sea el DNI, la cédula, carne de identidad, o como se le llame en cada pais), y este es el mas indicado para llave primaria (como tambien dijo delphius). Para el caso de las Empresas, estas tambien deben tener un codigo identificativo unico.

No entiendo muy bien esta parte que explicas

Esta base de datos se maneja poniendo una I  delante de los clientes que se han retirado por alguna razon o que solo estan registrados pero no envian datos a la empresa. Por eso el numero de esos clientes retirados esta disponible nuevamente.

Ejemplo el cliente  0500 se retira y ese numero se le asigna a otro cliente. Cuando vas a introducir un nuevo cliente es bueno consultar si ese numero se esta utilizando o no.

Que quieres decir con que "un cliente se retira", es que se elimina de la BD?
Por qué estaria disponible para otro el numero del DNI, si es único? (en el caso de que lo usaras como llave)

Sobre el tecleado por error de otro DNI a la misma persona, que aunque raro, pero pudiera darse, es error humano dificil de prever, pues puden haber mas de un Juan Perez en la misma empresa, como saber si es el mismo o son diferentes, si lo unico que lo diferencia es el DNI, y lo teclearon mal?

[eduarcol]

Opino lo mismo, deberas utilizar el numero de identificacion para poder ubicar rapidamente el registro,yo particularmente lo hago asi:

- El primer campo que se debe ingresar es el numero de identificacion del cliente.
- Se debe buscar en la BD el registro que cumpla con la condicion
- Si existe se muestran los datos en la pantalla y permites la modificacion o eliminarlo.
- Si no existe lo creas para que ingresen los datos nuevos.
- Aparte presento una pantalla de busqueda, donde puedes buscar el cliente por nombre o cualquier otro dato, lo que te permite ubicar el identificador de ese registro y colocarlo en la pantalla que lo necesitas.

[Wilson]

Hola Amigo Luck, contestame un par de cosas para pasar a sugerirte algo.
Tienes una Tabla Clientes con un campo único que haga referencia al número de identificación bien sea de la empresa o de la persona?

Tienes otra tabla Cuentas con un campo IdCliente que apunte como clave foránea a la tabla Clientes?

De lo contrario, podrías describir con alguna presición (script) la estructura de las tablas involucradas en el formulario que quieres mostrar, con esa información te desarrollo un pequeño ejemplo de como lo hago yo.

Saludos

[luk2009]

Gracias por sus respuestas
El problema es que el numero de cuenta del cliente no es su id personal si no un numero que se asigna desde la empresa y que el el mismo numero que envia el sistema de alarmas. Es la forma en que se ha hecho hasta ahora, pero podria cambiarse.

El ID de la persona o el RNC o cualquier otra cosa de la empresa no pueden ser las claves primarias. Esto porque el Sr. Juan Perez podria tener dos o mas casa con sistemas de alarmas instalados y entonces no funcionaria. De igual forma una Empresa puede tener varias sucursales y por lo tanto tampoco funcionaria para las empresas.

Wilson solo tengo una tambla clientes, no existe una tabla cuentas.

JoanCa el cliente que se retira es alguien que por ejemplo decide que no puede seguir pagando la iguala mensual, pero que si requiere alguna reparacion  en el futuro puede llamarnos y eso se cobra como un servicio. Por esta razon no se borran de la base de datos solo se pasan al renglon de inactivos. La idea es que los numeros sigan una secuencia 1,2,3,4,5 y que no haya saltos. Por eso se rellenan de nuevo. Pero debe existir un metodo mejor y Delphius tiene razon es una excepcion asi que vere  como ponerlo dentro de la regla.

[enecumene]

A ver Luk, porque está cabrón la cosa , colocanos la estructura de tu tabla para ver que campos y tipos de datos tiene y tomar una decisión a partir de ahí.

Saludos.