5 replies to this topic

[qtdpd]

Hola a todos !

Estoy desarrollado una aplicación en Delphi XE usando componentes ADO (pestaña dbGo) y la base de datos en Access.
De momento me funciona bien en un solo puesto pero tengo la necesidad de que funciona en red.

He seguido las instrucciones de "Caral" para configurar la bbdd en Red mediante fichero INI.

Tengo la base de datos instalada en la red a la que se accede mediante la ruta (\\servidor\bd\datos.mdb) y funciona perfectamente cuando la usan 2 usuarios pero:

¿Cómo hacer para que los cambios que yo haga los veo al mismo tiempo otro usuario y viceversa?

Tengo puesto los componentes siguientes:
ADOConection
ADOTable
ADOQuery
DataModule1

¿Cual sería la configuración ideal?

Gracias a todos por vuestras aportaciones.

[Wilson]

¿Cómo hacer para que los cambios que yo haga los veo al mismo tiempo otro usuario y viceversa?

Me temo que Access no dispone de tal funcionamiento. Si requieres de dicho comportamiento y el tiempo te lo permite te recomiendo que "te armes de valor" y des el salto hacia FIREBIRD que dispone de un mecanismo para lo que necesitas a través de sus famosos EVENTOS, además de soportar de mejor manera la concurrencia de usuarios.

En el foro encontrarás material que te puede ayudar, no te arrepentirás.

Aunque una solución muy poco ortodoxa sería colocar un Timer y programarlo para que cada intervalo de tiempo que escojas refresque el dataset (cuando no estás insertando o editando), más o menos así:

delphi

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  if  (ADOTable1.State = dsBrowse) then
    ADOTable1.Refresh;
end;

Esto te podría funcionar si tu aplicación es sencilla y no tiene una gran concurrencia.

Un cordial saludo.

[fredycc]

Comparto la opinión con Wilson, esta funcionalidad hasta donde me consta solo la podrás encontrar en PostgreSQL y Firebird; con los denominados eventos(IBEvent/ZIBEvent), que te permite hacer lo que requieres, con un poco de documentación lo conseguirás si lo deseas.

De otro modo no veo algo tan sencillo de implementar, porque obligarías a tener un proceso para verificar datos(tendrías pausas si lo colocas en el mismo thread), algo que se pondría complejo si deseas conectar más usuarios concurrentes en access y estar haciendo solicitudes por el otro usuario aún cuando no halla actualizaciones.

Saludos

[qtdpd]

Hola !

Gracias por contestar.

Tomo nota lo del "Timer" pero pensaba que había otra solución mejor 
Con respecto a Firebird lo tendré en cuenta pero es que ahora mismo necesito hacerlo en access.

[qtdpd]

Hola

La verdad es que ha quedado algo rústico con lo del Timer pero funciona 

He puesto un Timer a 30 segundos

delphi

procedure Tprincipal.Timer1Timer(Sender: TObject);
begin
//Actualización en RED
 if (trabajadores.State=dsBrowse) then trabajadores.Refresh;
 if (areas.State=dsBrowse) then areas.Refresh;
 if (permisos.State=dsBrowse) then permisos.Refresh;
end;

Y digo yo ¿ no sería mejor usar ADO con transacciones?

[Delphius]

Y digo yo ¿ no sería mejor usar ADO con transacciones?

Pues si bien ADO tiene la posibilidad de utilizar transacciones, que es la forma más segura de trabajar, el problema está en Access y en el propio diseño de ADO y de Jet4. Access no soporta transacciones.
Cuando uno utiliza las transacciones de ADO con Access se está generando una capa intermedia más, ya que debe emular el archivo de access como si se tratase de una base de datos SQL Server.
Como deben saber, el verdadero motor de base de datos es Jet4; Access es solo una fachada de acceso y muy rústica y simple. SQL Server también es una fachada, para el mismo Jet4... únicamente que está pensada para sacarle el verdadero uso.

Cuando se utiliza Access el trabajo con ADO, sin transacciones es algo como esto:
Aplicación <-> ADO <-> Access <-> Jet4

Cuando se utiliza transacciones sobre el archivo, debe hacerse como un "cast":
Aplicación <-> ADO <-> SQL Server(Access) <-> Jet4

Todo esto se debe a que la biblioteca de ADO para manejar las transacciones se comunica con bibliotecas que comparte con SQL Server, que luego se traducen en llamadas hacia las bibliotecas del motor Jet4.

La otra parte del problema es que ni ADO ni Jet4, y por tanto ni Access ni SQL Server tienen algo parecido a los eventos. Por tanto no resuelve de nada si se quiere hacer estos tipos de operaciones automáticas y de notificaciones. Obligadamente se tiene que recurrir a técnicas locales de refresco constantemente... llamadas que mayormente se hacen inutilmente.
El día en que doten al motor de algo parecido a los eventos... recién se podrá pensar en aliviar a los clientes.
Por algo yo digo: ¡Viva Firebird!   

Por cierto, esto de los eventos es uno de los temas que se han discutido en la conferencia sobre el estándar SQL-2008. El estándar ya tiene incorporado el concepto; algo que desde hace años lo tienen Firebird y PostgreSQL y más recientemente MySQL en una de sus últimas versiones. Creo que Oracle también tiene algo... el único que se ha quedado atrás es MS SQL Server porque Microsoft se opone rotundamente al nuevo estándar; cuando sus intenciones son, y casi diría que siempre ha sido, hacer que el estándar se apegue lo más fielmente al diseño de SQL Server y que los demás tengan que emularlo y adaptarse.

Otro motivo más para desapegarse de MS SQL Server.

Saludos,