43 respuestas en este tema

[eduarcol]

Simplemente genial lo que dices, lo tomare muy en cuenta, de hecho este sistema lo comenze con esa idea.  si pudieses ver la BD te darias cuenta que estan los BD de insercion y modificacion.

pero hubo un momento en que los componentes Zeos y los parametros en las sp se pelearon y no me quedo de otra por el tiempo tan reducido que tener que trabajarlo como tabla plana.

Para mi proxima aplicación estoy analizando otros componentes pero aun no me decido, ya que los ibx no me funcionaron a la primera y los dbx no los entiendo del todo.

[Rolphy Reyes]

Perfecto Eduardo.

Si necesitan ayuda sobre esto, me dan un toque, siempre sera de agrado ayudar....

[Delphius]

Disculpame Eduardo. Le he estado buscándole la vuelta pero tengo la mente atrofiada . Muy posiblemente el árbol no me deja ver el bosque . Leí una y otra vez el asunto, para ver por donde ajustar o cambiar.

Además no uso Zeos, y eso me limita.
¿Cómo estás manejando las transacciones? ¿Todo esto en una? ¿Separado? Me llama la atención el tema del nivel de aislamiento de las transacciones y la forma en como se la están usando, aunque no debería haber problema. Creo que por allí hay que darle una mirada.

Lo que si sería bueno es que limpies un poco esas instrucciones; me parece mejor que empleases parámetros.

Necesitaría despejar mi mente y volver a intentarlo.

Si avanzaste en algo y/o cambiaste algo nos pegas el grito .

EDITO: Cierto, está todo en una sola transacción .

Saludos,

[eduarcol]

es una sola transaccion debido a que es un solo documento lo que se esta guardando, lo de los parametros me encantaria pero el TZSqlProccessor no los acepta, esta entre otras razones me estan haciendo decidir alejarme de los Zeos.  Al paracer estan diseñados para trabajar al estilo tabla plana, muy buenos para dar el cambio de motor, aprendi mucho con ellos, pero creo que ya es hora de avanzar...

Ese es el problema que aparentemente lo que quiero no se puede, porque aun no se ha hecho el commit, pero mi duda es que me gustaria saber porque si todo esta en una misma transaccion

[Delphius]

Hola eduardo, yo sigo pensando en el tema. Y la verdad es que no logro asociar el problema

En principio con un nivel read commited se podría. Creo el problema se debe  al paso de INSERT a UPDATE, mezclado con los triggers en una sola transacción.

Me siento un tanto intranquilo por la forma de proceder. A mi suena más coherente una actividad como ésta:
1. Insertar una factura, indicando alguna referencia hacia el proveedor
2. Llenar los detalles, sin llenar el dato del proveedor
3. Una vez emitido el Commit, recíen lanzar un procedimiento almacenado que se encargue de actualizar los detalles, añadiendo el proveedor. Tal vez el SP recibe como parámetro el ID del proveedor.

Aunque también se puede hacer de forma directa:
1. Llenar cabecera
2. Llenar detalles

Luego, con las próximas ordenes de compra, se recalculan los costos, etc, pero no se ve alterado en ningún momento el proveedor.

Se me hace un lío porque se habla de facturas y por el otro lado orden de compras. Tal vez suene tonto la pregunta pero... ¿Que relación existe entre una factura y una orden de compra?

A ver si reordeno ideas: Al momento de cargar una factura ¿ésta se encarga de asociar el proveedor a los productos que no lo tienen?
Pero en otra ocasión, al inicio del tema, dices que se asocia el proveedor con una orden de compra.

¿Puedo ver un DER completo? Si me puedes explicar el proceso de forma más detallada y profunda tal vez se me aclaren bien las cosas. Hay algo peliagudo que no me cierra .
Tras días de pensar un poco hay algo que no me cierra y no me siento conforme con el diseño que tienes.

Saludos,

[eduarcol]

jeje, perdon por darte tanto dolor de cabeza, lo de orden de compra seguro es un error, jejeje estamos hablando de facturas de compra :D

el MER no lo tengo a mano, lo tengo en una unidad de respaldo, mañana traigo el cable para conectar la unidad y lo subo para que lo veas...

[Delphius]

No hay problema Eduardo, si no me duele la cabeza dejo de ser yo . Así que mientras me duela mi cabeza significa que estoy analizando, y pensando. Por lo general me deja de doler cuando el asunto queda arreglado.
Así funciono yo (y NewDelphius).

Gracias por aclararme el asunto de la orden de compra. Ahora duele menos .

Saludos,

[eduarcol]

Pensando un poco en la opción de Rolphy, que pasaria si abro una pantalla y esta abre la tabla del datamodulo de productos, y luego hago una factura, la cual moveria el mismo datamodulo, a lo que vuelva a la pantalla de productos se perderia la referencia al producto.  ¿Como se podria evitar esto?

[Delphius]

Pensando un poco en la opción de Rolphy, que pasaria si abro una pantalla y esta abre la tabla del datamodulo de productos, y luego hago una factura, la cual moveria el mismo datamodulo, a lo que vuelva a la pantalla de productos se perderia la referencia al producto.  ¿Como se podria evitar esto?

Puedes disparar un evento, y hacer que el sistema al recibir dicho evento se actualice o cierre y abra el dataset. O Lanzar un cartel de advertencia diciendo que alguien más ha estado trabajando los productos, pidiéndole que actualice la pantalla.

O si deseas puedes implementar el típico primitivo bloqueo pesimista, mediante la clásula WITH LOCK. Ejemplo de uso:

sql

SELECT ... FROM <algunatabla>
[WHERE ...]
[FOR UPDATE [OF ...]]
[WITH LOCK]
...;

Recomiendo la lectura del Release Note sobre este aspecto, y por supuesto lo que dice la FAQ.

Saludos,

[Rolphy Reyes]

Pensando un poco en la opción de Rolphy, que pasaria si abro una pantalla y esta abre la tabla del datamodulo de productos, y luego hago una factura, la cual moveria el mismo datamodulo, a lo que vuelva a la pantalla de productos se perderia la referencia al producto.  ¿Como se podria evitar esto?

Puedes disparar un evento, y hacer que el sistema al recibir dicho evento se actualice o cierre y abra el dataset. O Lanzar un cartel de advertencia diciendo que alguien más ha estado trabajando los productos, pidiéndole que actualice la pantalla.

O si deseas puedes implementar el típico primitivo bloqueo pesimista, mediante la clásula WITH LOCK. Ejemplo de uso:

sql

SELECT ... FROM <algunatabla>
[WHERE ...]
[FOR UPDATE [OF ...]]
[WITH LOCK]
...;

Recomiendo la lectura del Release Note sobre este aspecto, y por supuesto lo que dice la FAQ.

Saludos,

No existen mejores alternativas que las dadas por Delphius.

[eduarcol]

ok, lo tendre en consideración, todo esto apunta a dejar de utilizar los controles data-aware??

[Delphius]

ok, lo tendre en consideración, todo esto apunta a dejar de utilizar los controles data-aware??

Pues no te sabría decir amigo, Yo desde el primer momento en que empecé a leer sobre los componentes data-ware no les tuve demasiada confianza como para usarlos. No me terminan de convencer.
El problema no es que ese o no, sino que se realicen los controles adecuados para garantizar de que no existe alguna inconsistencia.

Para proyectos simples, y que no tienen muchas reglas de negocio y/o validaciones creo que con conectar estos componentes se puede tener un producto rápido y con poco código.

Más yo soy de la idea de no usarlos. No puedo decirte que no, ni que sí. Si tu vez que te resultan fáciles de usar, sigue utilizandolos. Ahora no te sabría decir hasta que punto es compatible la idea de data-ware + eventos o bloqueos optimistas en Firebird.

Saludos,

[eduarcol]

sinceramente aplicaciones grandes no he realizado, pero las que he sacado con controles data aware me han funcionado bien, de hecho me ahorran algo de trabajo, pero me da curiosidad si es algo bien utilizarlos o es cuestion de vagos y comprometo la integridad de la información?

[Delphius]

No creo que sea una cuestión de vagancia. Ni es mi idea dar una imagen como esa.

En realidad el peligro es el DataSource, y la propiedad AutoEdit. Gracias a esta propiedad es que los componentes Data-ware pueden aplicar los cambios. Cuando AutoEdit está en true, el DataSource envía el mensaje Edit hacia el dataset asociado y por tanto entra en el modo de edición.

Luego, los controles data-ware se pueden comunicar con el componente DataSource y de forma implícita pueden dar la orden Edit.
Esto es necesario cuando deseamos modificar registros, pero si no se realiza el control adecuado, en el lugar y momento adecuado cualquier persona puede hacer que el control dispare un mensaje que no esperamos en el momento menos oportuno, dejando al dataset, posiblemente, en un estado inconsiste con el que esperamos.

Claro, está, que se pueden aplicar correctos controles si tenemos los campos persistentes y hacemos uso de los eventos que disponen éstos. Para validaciones a nivel registro, claro está es mejor un control al nivel dataset.

Como vez amigo, en realidad quien tiene la culpa es el DataSource, quien hace de puente entre el dataset y los data-ware. Un mal despiste puede llevar a que el cursor se mueva, y termine apuntando a un registro inadecuado.

Por ello yo digo que emplear data-ware requiere de un poco más de control que si usáramos controles simples. Concentro mi esfuerzo en la lógica de negocio y en la de datos, y me despreocupo de si algún control por allí esté mal configurado y termine disparando y moviendo el cursor a otro lado.

Son ópticas que uno considera. Es todo muy subjetivo.

Saludos,

[eduarcol]

no he dicho que tu lo consideres de vagos, solo lo dije como para hacer referencia al ahorro de trabajo que traen.

[Rolphy Reyes]

Hasta el momento no he tenido problemas con los Data-Ware y los he usado en aplicaciones medianamente grande sin problema alguno.

Al DataSource lo primero que hago es ponerle la propiedad AutoEdit a False. Recuerden que los DataWare son los mismos componentes simples pero con el feature de comunicarse con el DataSet. Por ende yo programo mis metodos para Inserccion, Modificacion, Eliminado y demás.

Como desarrollo con DataModules por tablas, toda la logica del negocio esta alla, si necesito hacer alguna validación de un valor o algo de un campo; simplemente utilizo el evento OnValidate o el que aplique y mando una excepción que paraliza todo el proceso; como bien mencionas Delphius si estan peristentes, pero en caso de que no estuviesen de este modo, entiendo que se debe de sobrecargar o sobreescribir el metodo de Grabar para su ajuste necesario.

En mis inicios utilizaba "Edit's" me encontre muy tedioso esta modalidad, porque uno debe de efectuar validaciones que ya las hacen los DataWare, por mencionar un caso el tipo de dato (String, Integer), además de saber a que campo se refiere ese componente para luego enviarlo al metodo de Grabar, mientras que con los DataWare simplemente haces un Post y ellos saben a quien mandarselo (obviamente ya configurado adecuadamente).

Desde mi perspectiva, sí la rueda esta hecha porqué hacerla de nuevo!

[Delphius]

Hola Desde luego que el usar los componentes simples te toca llevar el control, y diseñar los métodos necesarios para preservar todo.

Ten en cuenta que yo tiendo a pensar de forma un tanto purista, y me llevo la idea de POO y el uso de tres capas al hombro. Eso me lleva a pensar que el módulo de datos no es del todo el mejor candidato a tener todas las reglas de negocio y la lógica.

Por ello me la pienso antes de tener todo en los módulos de datos. No siempre basta con tener los métodos y eventos de los campos persistentes y de los dataset.

Al menos eso pienso yo.
Desde luego, no es más que mi visión. Creo que nunca va a terminar este debate: ¿Data-ware o no data-ware?

Saludos,

[eduarcol]

bueno, que no termine porque recien se pone interesante

El problema que mas da con los controles no data aware es el que indica Rolphy, cargar y descargar la informacion en el control adecuado.

[Rolphy Reyes]

De acuerdo en que no todo debe de ir en el DataModule, sino también en el servidor de Base de datos, que por ser de este tipo debe de ser mejor que una PC de usuario.

Lo que si trato por todos los medios es nunca ligar la presentación (Formularios) con la lógica del negocio, para si en un futuro tuviese que cambiar los Formularios por otra cosa, además por la flexibilidad de la reutilización.

Es difícil dar por terminado el dilema de Data-Ware o no Data-Ware; si te sirve con Data-Ware pues adelante o te sirve con no Data-Ware adelante también, siempre llevar control.

[eduarcol]

todos dicen que separar las capas es lo primordial, y el desarrollado de PYMES?? no todos cuentan con la configuracion C-S y por lo general son instalaciones en un unico PC