Hello Ismael,
Thursday, December 2, 2010, 6:23:27 PM, you wrote:
ILDG> DBGrid, nunca he mirado el OwnerDrawGrid, por lo que no se que funciones ILDG> tiene, le echar� una mirada. Una pregunta funciona tanto enlazado a datos ILDG> con sin enlace?
ILDG> Vengo de Microsoft y la verdad que no he podido hacer ni una centena parte ILDG> de lo que hago all� y no he podido encontrar como resolver los problemas.
Yap, eso me pas� a mi tambi�n, bueno, parecido.
En el OwnerDrawGrid, tu haces todo, hasta pintar el contenido de las celdas. As� que creo que para lo tuyo no vale.
Tu "problema" es que vienes de MS donde las cosas con BDs se hacen en digamos 2 niveles.
Edici�n datos -> Base de datos
Mientras que en Lazarus, Delphi, y otros muchos se hacen en tres:
Edici�n datos -> Reglas de negocio -> Base de datos
Para un DBGrid esto ser�a m�s o menos:
DBGrid -> TSQLQuery -> Base de datos
Todas o casi todas las condiciones que has puesto como ejemplo se hacen en la capa de "reglas de negocio", como si un campo est� en blanco, eso lo compruebas en el "BeforePost". Con esto consigues que las reglas que rigen la integridad de los datos no sean dependientes del objeto visual que los edite, as� cambiar un TEditBox por un TComboBox requiere muy pocos cambios en el c�digo y ninguno en la l�gica de integridad de datos.
El �nico problema es cuando necesitas que los datos editados sean interdependientes entre diferentes registros de la base de datos, como por ejemplo (ficticio) en la entrada de un albar�n de venta que el operador no pueda vender el mismo producto dos veces en el mismo documento.
Este tipo de comprobaciones nos obligan a editar las lineas de un albar�n como un "todo" ya que deberemos mover el registro de la base de datos para comprobar que no haya sido introducido con anterioridad.
Yo en estos casos copio los datos actuales a un MEMDS y esos datos los edito con un TDBGrid, pero el memds no necesita accesos continuos a la BD, pero lo malo es que tengo que comprobar las reglas de negocio en el propio DBGrid es muchas ocasiones.
Resumiendo, haz todo lo que puedas en el TSQLQuery (BeforePost, AfterPost, beforeCancel, ...) y si hay algo que se escapa pues hay que irse a cosas m�s complicadas.
Best regards,
Jos�