FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
||||
|
||||
Con todo el respeto que Roman merece no estoy de acuerdo con esa metodologia, yo trabajo con personas que manejan gran cantidad de informacion y darle doble click a un registro para que aparezca otra ventana editar y volver a grabar cuando se trata de 300 a 500 veces al dia puede ser canson.
En el caso de vistas complejas yo lo que hago es que trabajo una tabla de memoria y luego actualizo. Las operaciones de edicion se solucionan con los eventos respectivos a nivel de Dataset, Field, Dbgrid, datasource
__________________
...Yo naci en esta ribera del arauca vibr@d0r Soy hermano de la espuma, de la garza, de la rosa y del sol... Viva Venezuela |
#22
|
|||
|
|||
Saludos a todos, gracias por los comentarios, los sigo provando y han funcionando muy bien sus soluciones y las estoy adaptando al proyecto.
Creo que tambien hicieron varias observaciones y comentarios, a lo cual les explico un poco, no estoy editando en el bdgrid ya que solo lo utilizo para consultas y tampoco es recomendable editar en el dbgrid ya tendrias algunos errores al insertar modificar y esto se por el tipo de objeto con el que lo tienes ligado, exactamente no conosto como funciona el objeto dbgrid, pero si lo tienes ligado con un tquery no te permitira editarlo y con un table lo podras editar pero he notado que no actualiza los campos cuando agregas mas de dos registros consecutivos, tienes que actualizar para poder continuar con tu registro. Saludos |
#23
|
|||
|
|||
Cita:
Pero, si, por el contrario, las ediciones no son demasiadas, pero sí tienes una multitud de campos, sería muy pesado para el usuario hacerlo en un DBGrid. Bye |
#24
|
||||
|
||||
Vuelvo a estar de acuerdo con las dos opiniones anteriores .
No obstante, sobre gustos no hay nada escrito. Yo, por mi propia experiencia, utilizo el DBGrid sólo para mostrar datos. No quiero decir con ello que para editar un registro de una tabla haya que abrir una nueva ventana (modal o no). Hay otras muchas maneras. Yo utilizo otras opciones para que 'parezca' que estás editando directamente sobre el DBGrid aunque realmente no sea así. No creo que sea momento de entrar aquí en como y cuando un método u otro es mejor. Las posibilidades de comprobación y de verificación son mucho más amplias si no editas dentro del propio Grid. Insisto, sobre gustos no hay nada escrito. Ademas, si las consultas se van complicando, incuyen 'joins', 'subconsultas', etc, se vuelve casi imposible editar en el DBGrid directamente. Por ello decidí desde un principio como 'norma' (mía...) el editar siempre fuera del DBGrid. Vuelvo a ser insistente .... con ello no quiero menospreciar la opinión de nadie.
__________________
Piensa siempre en positivo ! |
#25
|
||||
|
||||
Cita:
__________________
...Yo naci en esta ribera del arauca vibr@d0r Soy hermano de la espuma, de la garza, de la rosa y del sol... Viva Venezuela |
#26
|
||||
|
||||
Cita:
__________________
...Yo naci en esta ribera del arauca vibr@d0r Soy hermano de la espuma, de la garza, de la rosa y del sol... Viva Venezuela |
#27
|
|||
|
|||
De hecho, yo estoy de acuerdo con ambos. En lo particular casi nunca hago ediciones en el DBGrid, podría decir que también los uso de sólo lectura. Es sólo que me parecía un poco descabellado desaconsejarlo.
Ahora, realmente sería interesante debatir más al respecto. Por ejemplo, leo Cita:
Lo que sí creo, es que las posibilidades de edición son mucho más amplias con otros controles, y eso puede redundar en beneficio del usuario. Bye |
#28
|
||||
|
||||
De nuevo, de acuerdo.
Debatamos : Cada uno tiene su forma de programar. Personalmente hago muchísimas comprobaciones por cada campo de edición, no todas al final. Cambio algunas ediciones 'sobre la marcha' según el valor de determinados campos. Habrá otras muchas personas que prefieran hacer las comprobaciones al final, en el evento BeforePost o de otras maneras. Perfecto. Mi caso no es así. Otra pregunta que lanzo ahora yo, a lo mejor tengo conceptos equivocados .... La 'normalización' de mi base de datos es muy amplia, es decir, utilizo muchísimas tablas diferentes enlazadas por claves comunes. Por lo tanto, el 99% de mis Select's son con join's. Me equivoco, o no sería posible actualizar dos tablas diferentes enlazadas por un Select ... join en un único grid ? Hay miles de formas de programar. Cada cual elige la que más le gusta y más cómoda le resulte. Y por supuesto que es la facilidad de manejo para el usuario final la que debe de prevalecer en cada caso sin duda alguna. Y es por ello, que me decidí a utilizar los DBGrid sólo para mostrar datos
__________________
Piensa siempre en positivo ! |
#29
|
|||
|
|||
Esto se pone bueno
Cita:
Cita:
Bye |
#30
|
||||
|
||||
Ok, vayamos sacando algunas conclusiones, estamos de acuerdo en dos cosas:
Los registros muy grandes no se deben editar en un grid, al igual que las inserciones de las fichas de empleados y asi Los grid serian como para una especie de automatizacion del trabajo del transcriptor, cuando hay que modificar varios registros a la vez. En este caso no importa que tan grande sea, es necesario un dbgrid. Con respecto a los problemas de las validaciones siempre hay alternativas que en un dbgrid se pueden ejecutar todos los eventos que lograriamos en un control ordinario.
__________________
...Yo naci en esta ribera del arauca vibr@d0r Soy hermano de la espuma, de la garza, de la rosa y del sol... Viva Venezuela |
#31
|
|||
|
|||
Estoy de acuerdo con eduarcol en que la edicion debe ser sencilla para el usuario, ademas que entre mas facil es mas eficiente un usuario, tambien hay que tomar en cuenta que tipo de usuario final utilizara el proyecto (algo muy importante!!), entre mas facil para un usuario final mayor productividad y eficiencia.
En mi opinion es mas facil editar campos de tipo edit que un dbgrid, ya que al usuario se le hace mas practico ver los campos ordenados que en un renglon, ademas que evitamos que cambien o modifique otro renglon. Saludos |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Detectar evento cambio de foco | pborges36 | OOP | 28 | 26-05-2014 03:34:48 |
F9 - cambio de foco en pestaña | roman | La Taberna | 15 | 04-10-2006 08:46:03 |
Cambio al hacer foco con el mouse | c748a | OOP | 14 | 08-08-2005 17:31:35 |
Capturar El Evento Del Cambio De Foco En Un Form | murci | API de Windows | 11 | 21-01-2004 09:39:13 |
Foco de un edit | iriber | Varios | 6 | 26-11-2003 10:27:17 |
|