problema al refrescar tabla en firebird
Hola de nuevo,
Tal y como me habíais contestado en otro post a la hora de insertar, modificar.... un registro en una aplicación y que se pudiera ver reflejado en otro pc con event, si funciona si se dispara un mensaje de que se ha insertado un regisro, pero lo que no funciona es el refresh, ni abriendo ni cerrando la tabla, sigo teniendo que cerrar la aplicacion en el otro pc y volverla a abrir para ver reflejado el nuevo registro. No se si se me olvida algo para que se actualicen los datos pero creo que ya probe todo, incluso poner la tabla como edit y luego post y applyupdates. Alguna sugerencia? saludos y gracias |
Hola anubis.
Luego de la acción, ¿ Realizas Commit o CommitRetaining sobre la tabla en cuestión ? Saludos. |
Hola: Parto del supuesto después del commit tal como te pregunta ecfisa y supongo que has creado un trigger para firebird para tal caso, por ejemplo:
Obviamente el trigger anterior se dispara al momento de ingresar uno nuevo y logicamente despues del commit. Luego con la utilizacion de un IbEvents haces: Cuando se crea el formulario:
y en el event alert:
donde preguntamos si viene el evento new_reg hacemos el refresco del datasource que enlaza la grilla Se enuncia que firebird usa otro puerto adicional al 3050 para el procesamiento de eventos y lo asigna arbitrariamente. Estos es cierto y en su caso se configura editando el Firebird.conf en RemoteAuxPort a 6020 por ejemplo, habilita ese puerto en el firewall y listo.- Saludos |
Gracias por contestar,
Si, eso ya lo hice, si me salta el event cuando inserto un registro, pero el refresh no hace nada. |
Hola anubis.
No hay dudas que el evento se dispara y es recibido correctamente... ¿ En que componente no ves reflejado los cambios ? Saludos. |
Si, gracias.
En este caso en un dbgrid relacionado con el query. en el pc1 doy de alta el registro, le aplico post y resfresh, y lo veo en el dbgrid. en el pc2 cuando he dado de alta en el pc1 el registro, salta el evento le aplico refresh y no se actualiza en el dbgrid del pc2, tengo que cerrar la aplicacion en el pc1 y volverla a abrir para que aparezca el cambio. |
Cita:
Saludos. |
Si, tienes razon, pero es lo que hago, tanto cuando lo inserto en el pc1, como cuando salta el evento en el pc2, poner un zquery.refresh.
De todas formas, entiendo que el evento y lo que viene despues son independientes, por lo que el zquery.refresh ya lo he querido usar en otras partes de la aplicacion con los mismos resultados, el problema ya no es en si el evento, que si funciona, sino el zquery.refresh, que debiera de funcionar en cualquier parte de la aplicacion que lo coloque y se active, aunque sea tan solo asignado a un boton. esto lo digo porque ya estuve haciendo pruebas de diferentes formas y no hay nada |
Hola.
Cita:
Lo que comentas es un comportamiento extraño, con los componentes IBX siempre me ha funcionado correctamente. Tal vez haya que ajustar algún detalle en los componentes Zeos, pero lamento no poder ayudarte con ellos por no conocerlos. Saludos. :) |
no te preocupes.
Ya cree otra aplicacion pequeña con lo basico para probar y tampoco refresca los nuevos datos, si funciona el event. Algo se me escapa. Y si con los compentes zeos hay que modificar algo no se. |
Por decir algo.... ¿estás seguro que el dbgrid está asociado al datasource adecuado?
|
gracias casimiro,
si, es correcto, porque solo estoy haciendo pruebas con un solo query, y en el programa de prueba solo he puesto el zconnection, un datasource un query el dbgrid, para ver si actualiza con los componentes minimos pero tampoco. Dentro de la misma aplicacion si actualiza incluso sin refresh pero en la otra, una vez hecha la conexion con el zconnection de primera y teniendola abierta, como que ya no quiere recoger esos datos nuevos y el event si trabaja. Tambien he probado como dice caral en otro post, en cerrar y abrir el query. pero nada, no funciona. el problema es que no se trae los registros nuevos. |
Veamos, te lo han indicado 2 veces y creo que no has contestado: se supone que haces commit tras hacer post
Y después de contestar a lo anterior, pon el código que usas, explica un poco los componentes, propiedades, valores, etc. |
Si tienes razon, el commit es autocommit, de hecho cuando inserto un registro nuevo, queda la tabla actualizada, y eso lo veo abriendo el flamerobin y veo que el registro está ahi.
con la aplicacion nueva, no tengo codigo, le aplico nada mas el zquery1.refresh, tal y como indicais, enel momento que se dispara el evento. Solo he puesto, un zconnection, un zquery, datasource, y un dbgrid. Estoy usando componentes zeos 7, lazarus 1.1 y firebird 2.5. |
Cita:
|
Si, perdon.
Tengo una aplicación en el pc1 en el que meto los registros nuevos, y en el pc2, la aplicacion en la que debe verse esos registros nuevos sin cerrar el programa o desconectar y conectar a la base de datos. La cuestion, para probar, hice otra aplicacion en el pc2 sencilla, con un zconnection, zquery, datasource y un dbgrid, y un boton en que tengo puesto, zquery1.refresh; Uso el autocommit del zconnection. |
Perdon, ya encontre lo que me andaba fallando.
zconnection.transacisolationlevel lo tenia puesto en tinone, y lo he cambiado a tireadcommitted, con eso va perfecto y actualiza. gracias a todos. saludos. |
Se suponía que era algo de eso.
|
Hola
Yo tuve un problema parecido con un programa que, además de los EventAlert tenia el componente ApplicationsEvents (que no se si será tu caso). Le quité el componente ApplicationEvents sustituyendo su código por otra cosa y solucioné el problema. |
Cita:
|
Perdón; por otro código similar que podia sustituir al que tenia en el ApplicationEvents.
|
Por otro código que sustituía al que tenía en el ApplicationEvents (OnMessage). Es raro pero así es.
|
Buenas de nuevo, y perdonad que reabra un post antiguo.
En base al trigger que lance un evento en funcion de un insert en una tabla, ahora lo hice pero con update, el unico problema es que me lanza el evento una vez, despues de haber abierto el programa, aunque el refresh no me lo hace (que tendre que buscarle por otro lado porque estoy usando los mismos parametros en el zconnection que en los anteriores post y funciono). Aqui no entiendo porque, despues de hacer un edit y luego un post y finalmente un commit (commitretaing no lo tiene zeos), me salta el evento, pero despues de hacer lo mismo, ya no salta dicho evento. Estuve checando si tendria que ver con los cacheupdates pero ni modificandolos lo hace dos veces. Verdaderamente si esta bastante raro el asunto porque tambien hice un trigger para insertar y me hace lo mismo, solo lo hace una vez.
|
Bueno retomando este post, pero cambiando un poco el termino.
que tanto problema hay en activar o desactivar un query para que actualice, ya que el el metodo anterior, (post_event) no trabaja bien. me refiero a
bastantes veces. |
No pasa nada, salvo que si es un query muy pesado, harás trabajar mucho al servidor de bases de datos.
|
gracias, pense que habria algun problema con la corrupcion de datos ;). Pero es la forma que encontre de actualizar.
|
Hola amigos y perdon que reabra este post :(.
Aplicando los componente ibx en lazarus windows y, entendiendo que los events se disparan cuando hay alguna insercion por ejemplo, el refresh no trabaja con los nuevos datos. En ibtransaction, defaultaction esta puesto en tacommitretaining, en params esta puesto como read_committed, rec_version y nowait. Imagino que muchos de vosotros no teneis problemas con el refresh de un ibdataset en computadoras clientes puesto que os actualiza los datos y, como comentaba eficsa, que no ha tenido problemas con los componentes ibx. En una computadora doy de alta un usuario, y en la computadora del cliente tengo en pantalla un dbgrid abierta, el event salta pero no refresca, no quiero abrir y cerrar el dataset porque, como dice casimiro notevi, se le hace trabajar mucho al servidor de la base de datos. soy un caso verdad?. |
Cita:
No sé para qué tipo de negocio estás implementando eso, pero si un usuario/vendedor/contable/etc. está atendiendo a un cliente, no hay otro usuario/vendedor/contable/etc. atendiendo al mismo cliente, por lo que esas casualidades no se producen en la vida real. También recuerda que deben estar abiertos unos puertos adicionales, lee esto y esto. |
Hola anubis.
No he manejado los componentes IBX en Lazarus pero en Delphi, Refresh no es compatible con todos los TDataSet. Además, si se trata de una consulta estática se recomienda cerrarla y abrirla nuevamente. Por otro lado para actualizar un conjunto de datos, el método Refresh vuelve a solicitar los datos de la tabla, no creo que tengas una degradación de velocidad por elegir una u otra alternativa (cerrar/abrir). La ventaja mas notoria es que Refresh mantendrá la posición de la fila actual, pero eso también podes lograrlo usando Close/Open sobre TIBQuery como en este ejemplo:
Saludos :) |
Gracias por contestar.
La verdad no es por tener el dbgrid abierto a ver que sucede o si refresca, la realidad es que en un terminal estamos dando de alta, modificando o borrando productos, asi como cambiando los productos o aumentando el inventario, y en otro terminal de ventas (es una tienda al publico), vamos capturando los productos que estamos vendiendo. Si tengo la tabla abierta y en ese momento he dado de alta un producto o le he cambiado el precio debiera de actualizarse. Si bien es cierto que, como decis, el refresh no tiene porque funcionar en todos los escenarios, si me preocupaba usar close y open porque, segun lei en otro post, se le hace trabajar mucho al servidor de base de datos. Gracias casimiro notevi por los documentos, ya los habia visto y tambien el famoso post de 88 mensajes ;) pero ahi, independientemente de leerlo, finalmente se acaba usando, por un lado un commitretaining en el lado de modificacion de los registros y refresh en el lado del cliente. Por otro lado el problema de los puertos lo he solucionado abriendo el firewall para las computadoras en la red interna, de otra forma, solo con abrir el puerto 3050 no es suficiente. Resumiendo y dandoos las gracias por vuestra paciencia y aportes, no hay ningun problema en cerrar y abrir la tabla y, en este caso que apunta eficsa, guardando el bookmark. |
Cita:
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. |
Cita:
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 |
Cita:
Cita:
Cita:
|
Cita:
Cita:
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 Cita:
|
Cita:
Cita:
|
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 ;). |
Cita:
Cita:
|
Cita:
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. |
Cita:
|
Claro, es que el sistema cliente/servidor que hemos usado siempre necesita la seguridad de una buena conexión.
Para lo que comentas hay que pensar las cosas de otra forma, como las conexiones a la web. |
La franja horaria es GMT +2. Ahora son las 05:59:15. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi