¿Cómo puedo utilizar un cursor para captar registros actualizados en una base de datos con access?
Hola Compañero, je je otra vez te doy la coña, me surge una nueva pregunta. ¿Cómo ya te dije estoy realizando una aplicación multiusuario, pues bien la pregunta surge aquí, Mi jefe quiere que utilice un cursor de manera secuencial o sea que esté siempre abierto y leer los datos pulsando sobre una flechita,
así (<- ->) ok? Entonces cargo mi cursor con los datos de los clientes (por ejemplo), y me muevo a través del cursor, ¿pero cómo cojones detecto que otro usuario ha introducido un nuevo cliente desde otro ordenador?. En este caso necesito actualizar el cursor para que en todo momento los datos del cursor estén refrescados y éste contenga información de última hora. Pero como siempre NO TENGO NI PUTA IDEA. Espero que tu si la tengas. Saludos y buen VERANO.
así (<- ->) ok? Entonces cargo mi cursor con los datos de los clientes (por ejemplo), y me muevo a través del cursor, ¿pero cómo cojones detecto que otro usuario ha introducido un nuevo cliente desde otro ordenador?. En este caso necesito actualizar el cursor para que en todo momento los datos del cursor estén refrescados y éste contenga información de última hora. Pero como siempre NO TENGO NI PUTA IDEA. Espero que tu si la tengas. Saludos y buen VERANO.
1 respuesta
Respuesta de mmaynard
1
No sé si te comenté en otra respuesta (y si no lo hice, lo hago ahora) que yo procuro tener abierto un recordset el menor tiempo posible.
Ahora mismo estoy haciendo una aplicación para una compañía naviera que tiene oficinas por todo el mediterráneo. Tenemos las bases de datos centralizadas en dos servidores de SQL (lo cual nos da muy poca cobertura a la hora de dar salida a todas las peticiones que llegan cada segundo) ¿Te imaginas lo que me podría joder a mí el sistema si mantuviese un pantallazo con conexión directa al servidor más tiempo del necesario en uno de los clientes? Por otro lado, piensa en las necesidades que una compañía de trasporte puede tener en cuanto a "realidad" de la información y el momento en que se obtiene.
Por ejemplo, un barco no puede atracar en un puerto hasta que el puerto tiene la información de lo que lleva el barco, ya que en caso contrario sería contrabando, pero nosotros, en la oficina, no podemos pasar los datos del barco al puerto hasta prácticamente el momento en que éste está a punto de atracar.
Para que te hagas una idea, multiplica doce barcos que tenemos por una media de 800 contenedores que puede llevar cada barco y todo ello lo multiplicas por una media de a saber cuántos paquetes por cada contenedor... ¿tú sabes lo que es tener controlado cada pequeño paquetito que va en cada uno de esos contenedores de cada uno de esos barcos que va a algún puto puerto perdido en los confines de turquía con sólo dos servidores de SQL de mierda que no valen ni para tomar por culo?
He aquí el porqué de mi opción B y de porqué tengo siempre las conexiones abiertas, pero los recordsets cerrados. Yo no "abro recordsets", "entro por la puerta de atrás, los pinto en la pantalla y los cierro" y sólo los vuelvo a abrir bajo petición expresa del usuario.
A ver, hace poco estuve en una demostración en la que me pretendían vender un sistema operativo llamado Velázquez (busca la empresa Ática y el sistema de desarrollo Visual Velázquez en internet y vas a flipar) y me hicieron la siguiente demostración: con una conexión a 56 kbs (es decir, más mala que la leche) el servidor de velázquez devolvió unos dos millones de registros en menos de un minuto. ¿Tú sabes lo que es eso? Se me quedaron los ojos como platos y, cuando le pregunté al desarrollador que cómo era eso posible, lo único que se le ocurrió responder fue "hay maneras y maneras de programar". Y tenía toda la puta razón del mundo, ¿de qué me sirve una conexión punto a punto con ADSL a 2 Megas si mis programas están mal hechos? ¿Para qué quiero unos sistemas de telecomunicaciones acojonantes si luego mantengo un recordset (programado con ADODB sobre VB) abierto constantenmente?
¿Dices qué tu jefe quiere los datos constantemente actualizados? Oblígale a pedirlos, pero no le dejes en la vida mantener un pantallazo abierto más de unos segundos con conexión a tu base de datos (y más si me estás diciendo que es Access)
Aquí estás en el punto de tener que engañar a tu jefe y tienes mil maneras de hacerlo. A veces es más rentable (en entornos multiusuario, ojo, que para una única máquina nada de esto tiene sentido) abrir dos recordsets utilizando "SELECT WHERE" que utilizar el método MoveNext (con el que te estás jugando la integridad de los datos)
Piensa una cosa: ADODB (DAO, RDO, etc, etc) no son más que herramientas que se nos pusieron a disposición de aquellos a los que nos nos gusta picar código, pero siempre que el código no lo piques tú, en cierto modo, te estás vendiendo un poco.
MoveNext, MovePrevious ¡NO!
Si quieres utilizar los botones del estilo <- y -> (invento de windows por excelencia) cúrratelo para que cada uno de ellos abra un recordset en una u otra posición, pero evitalos en lo que puedas.
No sé si me explico, vamos, que procures cambiar esa concepción, que ahora puede que no tengas problemas por tener un RecordSet abierto, pero que no estaría de más que te fueras acostumbrando (y aprendiendo) opciones B más rentables.
Por cierto, si quieres una respuesta a tu pregunta... Juega con las opciones de apertura del recordset. Ábrelo en modo Dinámico, usa las opciones del refresco de la pantalla y de los objetos y utiliza herramientas que te permitan hacer ReQuerys.
Tendrás una aplicación a pedales, eso sí, actualizada en cada momento ( ;) )
A trompicones, pero actualizada.
P.D.: Procura no hacer demasiado caso a tu jefe si no ha picado en su vida, al menos, las mismas líneas de código que tú. Haz lo que hacemos todos, si quiere algo que tú no quieres hacerle "reinínicale el ordenador" ("... morfeo cree que eres el elegido... si alguna vez te encuentras con un agente, haz como hacemos todos, ¡corre!...")
P.D2.: Buen verano
Ahora mismo estoy haciendo una aplicación para una compañía naviera que tiene oficinas por todo el mediterráneo. Tenemos las bases de datos centralizadas en dos servidores de SQL (lo cual nos da muy poca cobertura a la hora de dar salida a todas las peticiones que llegan cada segundo) ¿Te imaginas lo que me podría joder a mí el sistema si mantuviese un pantallazo con conexión directa al servidor más tiempo del necesario en uno de los clientes? Por otro lado, piensa en las necesidades que una compañía de trasporte puede tener en cuanto a "realidad" de la información y el momento en que se obtiene.
Por ejemplo, un barco no puede atracar en un puerto hasta que el puerto tiene la información de lo que lleva el barco, ya que en caso contrario sería contrabando, pero nosotros, en la oficina, no podemos pasar los datos del barco al puerto hasta prácticamente el momento en que éste está a punto de atracar.
Para que te hagas una idea, multiplica doce barcos que tenemos por una media de 800 contenedores que puede llevar cada barco y todo ello lo multiplicas por una media de a saber cuántos paquetes por cada contenedor... ¿tú sabes lo que es tener controlado cada pequeño paquetito que va en cada uno de esos contenedores de cada uno de esos barcos que va a algún puto puerto perdido en los confines de turquía con sólo dos servidores de SQL de mierda que no valen ni para tomar por culo?
He aquí el porqué de mi opción B y de porqué tengo siempre las conexiones abiertas, pero los recordsets cerrados. Yo no "abro recordsets", "entro por la puerta de atrás, los pinto en la pantalla y los cierro" y sólo los vuelvo a abrir bajo petición expresa del usuario.
A ver, hace poco estuve en una demostración en la que me pretendían vender un sistema operativo llamado Velázquez (busca la empresa Ática y el sistema de desarrollo Visual Velázquez en internet y vas a flipar) y me hicieron la siguiente demostración: con una conexión a 56 kbs (es decir, más mala que la leche) el servidor de velázquez devolvió unos dos millones de registros en menos de un minuto. ¿Tú sabes lo que es eso? Se me quedaron los ojos como platos y, cuando le pregunté al desarrollador que cómo era eso posible, lo único que se le ocurrió responder fue "hay maneras y maneras de programar". Y tenía toda la puta razón del mundo, ¿de qué me sirve una conexión punto a punto con ADSL a 2 Megas si mis programas están mal hechos? ¿Para qué quiero unos sistemas de telecomunicaciones acojonantes si luego mantengo un recordset (programado con ADODB sobre VB) abierto constantenmente?
¿Dices qué tu jefe quiere los datos constantemente actualizados? Oblígale a pedirlos, pero no le dejes en la vida mantener un pantallazo abierto más de unos segundos con conexión a tu base de datos (y más si me estás diciendo que es Access)
Aquí estás en el punto de tener que engañar a tu jefe y tienes mil maneras de hacerlo. A veces es más rentable (en entornos multiusuario, ojo, que para una única máquina nada de esto tiene sentido) abrir dos recordsets utilizando "SELECT WHERE" que utilizar el método MoveNext (con el que te estás jugando la integridad de los datos)
Piensa una cosa: ADODB (DAO, RDO, etc, etc) no son más que herramientas que se nos pusieron a disposición de aquellos a los que nos nos gusta picar código, pero siempre que el código no lo piques tú, en cierto modo, te estás vendiendo un poco.
MoveNext, MovePrevious ¡NO!
Si quieres utilizar los botones del estilo <- y -> (invento de windows por excelencia) cúrratelo para que cada uno de ellos abra un recordset en una u otra posición, pero evitalos en lo que puedas.
No sé si me explico, vamos, que procures cambiar esa concepción, que ahora puede que no tengas problemas por tener un RecordSet abierto, pero que no estaría de más que te fueras acostumbrando (y aprendiendo) opciones B más rentables.
Por cierto, si quieres una respuesta a tu pregunta... Juega con las opciones de apertura del recordset. Ábrelo en modo Dinámico, usa las opciones del refresco de la pantalla y de los objetos y utiliza herramientas que te permitan hacer ReQuerys.
Tendrás una aplicación a pedales, eso sí, actualizada en cada momento ( ;) )
A trompicones, pero actualizada.
P.D.: Procura no hacer demasiado caso a tu jefe si no ha picado en su vida, al menos, las mismas líneas de código que tú. Haz lo que hacemos todos, si quiere algo que tú no quieres hacerle "reinínicale el ordenador" ("... morfeo cree que eres el elegido... si alguna vez te encuentras con un agente, haz como hacemos todos, ¡corre!...")
P.D2.: Buen verano
Je je.No me sorprende tu respuesta en absoluto, me has descrito con tus palabras todas las ideas que corren en mi cabeza con respecto a lo que estoy haciendo. Muchas gracias por tus explicaciones tna constructivas. Tomaré nota. Saludos
