problema al refrescar tabla en firebird

[[RONPABLO]]

Empezado por Casimiro Notevi

Por eso no necesitas refrescar nada.
Si estás vendiendo mientras se está actualizando un precio (por ejemplo), lo normal es que se venda al precio que tiene en el momento de la venta. Una vez actualizado el precio, en la siguiente venta irá el nuevo precio. Pero no hay que actualizarle el precio al cliente que compró con el precio viejo, él lo compró a ese precio.

Pero no el caso va más allá del precio desde donde yo lo veo, puede pasar que hayan 3 artículos y por equis o ye razón ya no se encuentren disponibles, así pues se podría vender algo que ya no se encuentra en el inventario.


Por otro lado anubis el refresh es un open close encapsulado en una sola instrucción, así que usar el refresh o usar las dos instrucciones va a tener los mismos consumos de tiempo.

También ve preparándote para bloqueos de la aplicación cuando se pierda la conexión web (cerrar la tapa de un portatil, que se desconencte por error el cable de red, que se quede sin energia el router), y problemas de velocidad en redes inalambricas ya que los ibx no están muy preparados para lidiar con ellos, mucho menos esperes conectarte muy bien por Internet, también ten en cuenta que para trabajar con los eventos de firebird debes desbloquear además del puerto 3050, el puerto 3052 del firewall, no solo en el servidor si no en los clientes ya que por dicho puerto les llega el mensaje del evento

[Casimiro Notevi]

Empezado por RONPABLO

Pero no el caso va más allá del precio desde donde yo lo veo, puede pasar que hayan 3 artículos y por equis o ye razón ya no se encuentren disponibles, así pues se podría vender algo que ya no se encuentra en el inventario.

Obviamente, las verificaciones se realizan al momento de grabar. Si vas a vender un artículo y dejas la venta en pantalla, mientras alguien en otro sitio realiza la venta del mismo artículo y termina, el primero se quedó sin artículos. Eso es lógico, pero nunca ocurrirá, no habrá problema, porque si hay 3 artículos y tú te los llevas, entonces el otro cliente es imposible que los tenga, físicamente hablando.

Empezado por RONPABLO

También ve preparándote para bloqueos de la aplicación cuando se pierda la conexión web (cerrar la tapa de un portatil, que se desconencte por error el cable de red, que se quede sin energia el router), y problemas de velocidad en redes inalambricas ya que los ibx no están muy preparados para lidiar con ellos, mucho menos esperes conectarte muy bien por Internet,

Todo eso es independiente de la lógica de negocio, no debe interferir en nada en los procesos.

Empezado por RONPABLO

también ten en cuenta que para trabajar con los eventos de firebird debes desbloquear además del puerto 3050, el puerto 3052 del firewall, no solo en el servidor si no en los clientes ya que por dicho puerto les llega el mensaje del evento

Firebird trabaja de forma predeterminada por el puerto 3050.

[[RONPABLO]]

Empezado por Casimiro Notevi

Obviamente, las verificaciones se realizan al momento de grabar. Si vas a vender un artículo y dejas la venta en pantalla, mientras alguien en otro sitio realiza la venta del mismo artículo y termina, el primero se quedó sin artículos. Eso es lógico, pero nunca ocurrirá, no habrá problema, porque si hay 3 artículos y tú te los llevas, entonces el otro cliente es imposible que los tenga, físicamente hablando..

si yo entiendo, se podría tratar de varias formas, por ejemplo se puede hacer una verificación en el proceso de la venta, de tal forma que al dar click en vender corrobore que aun queda productos y así informar al cliente que se acabo dicho producto poco antes de que se realizara la compra, pero es solo para mostrar que desde cierta logica tiene su razón de ser, que se puede dar muchos tratamientos es verdad, pero el mostrar en tiempo real los cambios que va teniendo un articulo es una petición relativamente normal según que necesidad.

Empezado por Casimiro Notevi

Todo eso es independiente de la lógica de negocio, no debe interferir en nada en los procesos.

Todos esos son los problemas que yo he tenido que vivir por características de los ibx, y al tener mi aplicación como un cliente que consulta a firebird desde el mismo equipo o desde un equipo remoto, hoy por hoy ya trabajo muy poco firebird y delphi (solo una aplicación que hice para mi), pero hoy en día haría una aplicación servidor la cual sería la encargada de conectarse con firebird o cualquier base de datos, en donde si yo tengo una tabla llamada Personas, por medio de los mismos IBX o cualquier componente de acceso a datos, seleccionar la información de una Persona y convertirlos en un objeto Persona (que viene de una clase persona que ya hemos creado), dicho objeto deberá ser capaz de ser transformado a texto o a alguna forma de serializar, y además de ser capaz de deserializar o revertir la conversión y volver a ser un objeto persona y dicho objeto persona comunicarse con el dataset y guardar la información.
Por otro lado tener una aplicación cliente que le haga peticiones a la aplicación servidor, por ejemplo decirle que le mando serializado la información que tiene para un documento de identidad cualquiera, e internamente también convertir a un objeto Persona en dicha aplicación cliente, además realizar los diversos procesos que se necesiten hacer con dicha persona (lógica de negocio) y si hay cambios en el objeto persona serializarlo, enviarlo a la aplicación servidor y pedirle que haga los cambios pertinentes a dicha persona... Como tal es mucho trabajo inicial, pero años después será un alivio

Empezado por Casimiro Notevi

Firebird trabaja de forma predeterminada por el puerto 3050.

Si todo el proceso de base de datos va por el 3050, pero los eventos los manda por el 3052 y tanto el firewall de windows o como varios antivirus lo bloquean, y puede hacer creer que se encuentra un daño en la aplicación

[Casimiro Notevi]

Empezado por RONPABLO

Todos esos son los problemas que yo he tenido que vivir por características de los ibx, y al tener mi aplicación como un cliente que consulta a firebird desde el mismo equipo o desde un equipo remoto, hoy por hoy ya trabajo muy poco firebird y delphi (solo una aplicación que hice para mi), pero hoy en día haría una aplicación servidor la cual sería la encargada de conectarse con firebird o cualquier base de datos, en donde si yo tengo una tabla llamada Personas, por medio de los mismos IBX o cualquier componente de acceso a datos, seleccionar la información de una Persona y convertirlos en un objeto Persona (que viene de una clase persona que ya hemos creado), dicho objeto deberá ser capaz de ser transformado a texto o a alguna forma de serializar, y además de ser capaz de deserializar o revertir la conversión y volver a ser un objeto persona y dicho objeto persona comunicarse con el dataset y guardar la información.
Por otro lado tener una aplicación cliente que le haga peticiones a la aplicación servidor, por ejemplo decirle que le mando serializado la información que tiene para un documento de identidad cualquiera, e internamente también convertir a un objeto Persona en dicha aplicación cliente, además realizar los diversos procesos que se necesiten hacer con dicha persona (lógica de negocio) y si hay cambios en el objeto persona serializarlo, enviarlo a la aplicación servidor y pedirle que haga los cambios pertinentes a dicha persona... Como tal es mucho trabajo inicial, pero años después será un alivio

No lo he entendido

Empezado por RONPABLO

Si todo el proceso de base de datos va por el 3050, pero los eventos los manda por el 3052 y tanto el firewall de windows o como varios antivirus lo bloquean, y puede hacer creer que se encuentra un daño en la aplicación

No, no es así, son puertos "aleatorios", pero no el 3052.

[anubis]

Entiendo todo lo que decis de verdad, el gran problema del refresh, por muy encapsulado que este siendo un close open como decis, no actualiza si he añadido un nuevo producto, realmente tengo que cerrar y abrir.
Otra situacion es las ventas hasta el momento, evidentemetne si un cliente esta comprando a x precio y luego tu se lo cambias, lo estas cambiando en la tabla principal de precios por ejemplo, las ventas actuales estan en, digamos, en la tabla de ventas que solo recoge de la tabla de productos-precios cuando se añade un codigo.
Asi mismo, como comentaba mas arriba, la unica forma de ver si actualiza el refresh, es viendolo en un dbgrid en el momento, cosa que no ocurre con el refresh pero si con close y open.

Vosotros, amigos, sabeis mas que uno, por eso preguntamos los que no sabemos o somos muy burros para entender a la primera .
Por otro lado es la forma correcta de programacion o diseño de las bases de datos. Como dice e insiste en otros post casimiro notevi, cerrar y abrir muchas veces las tablas, en teoria, no hay problema, solo que se le hace trabajar mas al servidor, cosa, por cierto, si estan conectados varios cliente a la vez, si puede llegar a saturar en funcion de la maquina.
Si he optado por usar ibx es porque siempre los recomendais por rapidos y mas cosas que no recuerdo siendo esta, es la base de todo, aprender y que otros aprendan de vosotros, los maestros. .

se agradece todo el esfuerzo y compresion .

[[RONPABLO]]

Empezado por Casimiro Notevi

No lo he entendido

Es que me enredo explicando, al tener una aplicación cliente que se conecta directamente a la base de datos se suelen tener muchos problemas, la mayoría de información, tutoriales y cosas similares que uno encuentra de por ejemplo IBX son muy viejos y te terminan enseñando a trabajar con un esquema de conexión que no es optimo para las necesidades de hoy día, donde todo el tiempo te encuentras conectado al servidor (se que se puede hacer de otras formas pero la mayoría te orienta así), donde la perdida de conexión se ve reflejada en bloqueos de la aplicación o donde una aplicación que iba a ser para una red de equipos conectados por cable ya te piden (y te pagan obviamente) para que soporte conexiones por internet (y ahí en la nube los ibx no son la mejor opción y adaptarlo traerá grandes problemas)... En fin para evitar eso es que opino que uno debería arrancar los proyectos nuevos con arquitecturas tales como REST o DataSnap (el cual no he trabajado), o hacer una aplicación servidor que haga de intermedio entre la base de datos y los diversos clientes, y que en los clientes nunca debe de haber componentes que le den acceso a la base de datos (IBX, Ado o similares)

Empezado por Casimiro Notevi

No, no es así, son puertos "aleatorios", pero no el 3052.

Tienes razón, ahora mirando un poco atrás para solucionar el problema del firewall nos tocaba dejar los eventos en un puerto fijo con la instrucción RemoteAuxPort que se puede marcar en el archivo de configuración de firebird

[Casimiro Notevi]

Empezado por RONPABLO

al tener una aplicación cliente que se conecta directamente a la base de datos se suelen tener muchos problemas, la mayoría de información, tutoriales y cosas similares que uno encuentra de por ejemplo IBX son muy viejos y te terminan enseñando a trabajar con un esquema de conexión que no es optimo para las necesidades de hoy día, donde todo el tiempo te encuentras conectado al servidor (se que se puede hacer de otras formas pero la mayoría te orienta así), donde la perdida de conexión se ve reflejada en bloqueos de la aplicación o donde una aplicación que iba a ser para una red de equipos conectados por cable ya te piden (y te pagan obviamente) para que soporte conexiones por internet (y ahí en la nube los ibx no son la mejor opción y adaptarlo traerá grandes problemas)...

Que sean viejos no quiere decir nada, más viejo es delphi
Al principio eran los FreeIBcomponents (libres y gratis), que los usó Borland y los renombró a IBX (InterBase eXpress), de ahí salieron varios más, entre ellos los estupendos FIBplus.
Se han ido actualizando, igual que Delphi. Incluso hay una versión para Lazarus con versión para Linux (es la que tengo instalada) y es muy nueva, la última actualización es de hace solamente una semana: http://www.mwasoftware.co.uk/ibx

En todos estos años que he usado esos componentes, desde 1998, me han funcionado perfectamente, son muy seguros, muy estables, los más rápidos, ...
Ahora bien, que no están pensados para internet, pues no, no están pensados para internet. Pero más bien es lo que has dicho al final, que para funcionar por internet hay que usar unos métodos distintos al habitual de cuando estás conectado a una red local/intranet.

[[RONPABLO]]

Empezado por Casimiro Notevi

Que sean viejos no quiere decir nada, más viejo es delphi
Al principio eran los FreeIBcomponents (libres y gratis), que los usó Borland y los renombró a IBX (InterBase eXpress), de ahí salieron varios más, entre ellos los estupendos FIBplus.
Se han ido actualizando, igual que Delphi. Incluso hay una versión para Lazarus con versión para Linux (es la que tengo instalada) y es muy nueva, la última actualización es de hace solamente una semana: http://www.mwasoftware.co.uk/ibx

En todos estos años que he usado esos componentes, desde 1998, me han funcionado perfectamente, son muy seguros, muy estables, los más rápidos, ...
Ahora bien, que no están pensados para internet, pues no, no están pensados para internet. Pero más bien es lo que has dicho al final, que para funcionar por internet hay que usar unos métodos distintos al habitual de cuando estás conectado a una red local/intranet.

Como tal no critico a los IBX, de hecho creo que son muy buenos y muy probablemente serán mi primera opción a la hora de trabajar un nuevo proyecto, digo que la documentación que más se encuentra te guía a usar practicas que para necesidades muy actuales no son la adecuadas. Es tan simple como que montar una red cableada es costosa comparada a comprar un router inalambrico, ya los IBX van teniendo ciertos problemas (directos o indirectos) con redes inalambricas porque la velocidad es mucho menor a la de una cableada, porque muchos equipos para ahorrar energía desconectan redes inalambricas o porque simplemente al prender otro router cercano puede interferir y tumbarse mutuamente (que este caso ya se ve menos, pero aún se ve).