FiveTech Software tech support forums

Un saludo a todos los colegas del Foro

Estoy largo rato intentando encontrar la solución a este problema y me doy por vencido.

He implementado un BROWSE en el cual se dan las típicas opciones de Modificar, Adicionar y Eliminar Registros, usando los métodos del objeto Recordset de ADO. Funciona Muy bien cuando se trabaja con una sola estación (estacion1); pero cuando desde estacion2 se realiza algún cambio, adición o eliminación, estos no se reflejan en el Browse de estacion1. Entonces si por ejemploi el usuario de estacion1 trata de eliminar lo que estacion2 ya eliminó se produce el consiguiente error devuelto por el proveedor OLEDB.

La localización del Cursor está definido del lado del cliente
oRs:CursorLocation = adUseClient

El Objeto se abre usando estos parámetros
oRs:Open( cQuery , cConnection, adOpenKeyset, adLockOptimistic )

incluso he probado usando adOpenDynamic, que según los manuales permiten ver todo tipo de cambios de otros usuarios, pero nada.

He tratado de probar usando las propiedades OriginalValue y UnderlyingValue (valor que tiene en la base de datos) pero los valores que se obtiene son los mismos que tiene el recordset en ese momento, no permitiéndome controlar el valor actual en la base de datos y el valor actual en el recordset local.

Cómo podría refrescar el BROWSE de estacion1 con los _ ocurridos en El Servidor de Base de Datos y que lo realizó estacion2?

Pienso que si uso Requery() cada momento que me muevo por cada elemento del Browse, en una tabla grande y en internet se volvería muy lenta y el moverme sería un caos, porque en el requery se recargan los datos y el cursor siempre va a la ultima fila.

Una opción que se me ocurre es capturar los mensajes de error del proveedor OLEDB y en base a estos actuar recargando los nuevos datos. Pero esta parte es la que no se como hacerlo aún. Cómo hago con Harbour para capturar los errores de ADO?

Espero que alguien pueda darme alguna pista o si ya lo tiene resuelto me indique cómo controlar _.

Desde ya muy agradecido

Marcelo Jingo

Marcelo,

Para conseguir un 'browse' a lo xBase debes tener en cuenta:

a. Que el proveedor que utilizas sea capaz de manejar cursores dinámicos.

b. Que abras un recordset cliente y dinámico.

No obstante lo anterior, abrir un recordset de esas características, cuando hay varios terminales 'atacando' al mismo 'browse' puede que el servidor se atasque.

Si necesitas más información puedes mirar la ayuda de ADO y tambien puedes echar un vistazo a este artículo http://www.capelblog.com/?p=58

Gracias por tu interés José Luis.

Seguiré buscando la forma..., creo que en este punto voy a tener que hacer consultas SQL independientes usando el objeto command para comparar entre el valor actual del field del recordset y el que me entregue la consulta.... seguiré probando


Un saludo

Marcelo Jingo

Marcelo,

Seguiré buscando la forma..., creo que en este punto voy a tener que hacer consultas SQL independientes usando el objeto command para comparar entre el valor actual del field del recordset y el que me entregue la consulta.... seguiré probando

Quizás no te he entendido bien...

¿Te refieres a tener un recordset con actualización dinámica o te refieres a la actualización de una fila?

José Luis,

Como dije, si un solo usuario se conecta al Servidor de Base de Datos(MySQL), no hay problema, el browse del recordset trabaja muy bien realizando actualizaciones, altas o eliminando registros, usando sus respectivos métodos, cuyas modificaciones se reflejan inmediátamente en el Servidor.

Pero si 2 o más usuarios usan el mismo recordset y uno de ellos por ejemplo elimina un registro, este cambio no se refleja en el browse del otro usuario, pudiendo este último (que aún lo ve en su browse) tratar de eliminar el que ya no existe en la Base de Datos, haciendo que se genere un error.

Lo más fácil sería colocar un botón que ejecute el método Requery, y que el usuario lo ejecutaría cada vez que vaya a realizar un cambio y así tenga la versión más actual de los datos. Pero esto no me parece muy práctico.

Es por eso que yo me inclinaba por el lado de capturar los Errores del Proveedor de OLEDB, para que sólo cuando se genere el error mostrar el mensaje respectivo, y luego hacer un requery o regenerar todo el recordsete.

Por eso va mi pedido a quienes puedan ayudarme y guiarme en este asunto.

De antemano muchas gracias
Saludos

Marcelo Jingo

Amigo y por que no simplemente colocas un timer() para que refresque el browse, creo que esto soluciona tu problema.

Un Saludos

LEANDRO ALFONSO

Saludos Leandro

Si no puedo capturar los errores desde Harbour, probaré pasándome a xHarbour que allí sí creo que se puede capturarlos usando TRY CATCH END. Si eso no funciona trataré de utilizar el TIMER que me recomiendas. Lo que se intenta es que la aplicación consuma menos recursos tanto del equipo como e la red.

Seguiré con mis pruebas y ya les comentaré. Gracias Leandro

Marcelo Jingo

Es necesario un timer

cuando se usa un browse para monitorear los datos,

activate dialog oDlg centered on init ( mitimerOn() )

static function MiTimerOn()
DEFINE TIMER oTimer of oDlg INTERVAL 5000 ACTION TimerAction()
activate timer oTimer
return

César y Leandro

He probado colocando el timer, en efecto funciona ..... peeero, sucede lo que ya esperaba, que apenas si estoy navegando por el browse, este se va a la primera fila, cada intervalo que se ha definido el timer. impidiendo una navegación limpia.

Creo que tendré que implementar un control más riguroso en el recordest, como guardar el número de fila actual y al refrescar volver a la fila gusadada y............ más cosas.

De todas formas gracias por todo y seguiré probando, es más ya me pasé a xHarbour para probar el control de errores con TRY CATCH.

Un Saludo

Marcelo Jingo

Marcelo,

¿Puedes mostrarnos cómo creas el recordset?
¿Contra cual base de datos?
¿Cual proveedor usas?

Gracias José Luis, César y Leandro.

Con el apoyo de todos ya lo he solucionado y me funciona perfecto. La solución fue colocar el timer y controlando los posibles errores que podemos encontrar en la navegación.

Gracias de nuevo.

Marcelo Jingo