Como seguramente ya sabes, puedes usar Firebird con 4 arquitecturas diferentes:

  • Classic
  • SuperClassic
  • SuperServer
  • Embedded

Las tres primeras normalmente tienen al Servidor en una computadora y al Cliente en cada una de las computadoras que necesitan acceder a la/s base/s de dato/s. Una de esas tres primeras arquitecturas debemos usar cuando queremos que varios usuarios estén conectados al mismo tiempo a la misma Base de Datos, este es el caso más frecuente cuando usamos Firebird. Colocamos a las bases de datos en una carpeta no compartida que se encuentra en la misma computadora donde se encuentra el Servidor y éste es quien se encarga de acceder a esas bases de datos cuando los Clientes se lo soliciten. Eso está muy bien y funciona perfectamente.

La arquitectura Embedded en cambio la usaríamos cuando siempre será una sola persona quien se conectará a la Base de Datos, como sería en el caso de una aplicación monousuario.

¿Y qué ocurrirá si ponemos a la Base de Datos en una carpeta compartida y permitimos que accedan a ella desde varias computadoras de la red usando Embedded?

Que ocurrirá una catástrofe y se destrozará y volverá inservible a la Base de Datos.

¿Por qué eso?

 Porque Embedded puede manejar varias conexiones, pero con la condición de que todas esas conexiones correspondan a un mismo proceso. Siendo así, él administrará los cambios a las páginas correctamente, evitando que una conexión sobre-escriba los cambios hechos por otra conexión.

Sin embargo, si desde varias computadoras se está accediendo mediante Embedded a una Base de Datos que se encuentra en una carpeta compartida se terminará con esa Base de Datos destruida.

 Eso es debido a que cada Embedded cree que tiene acceso exclusivo a la Base de Datos y realiza en ella los cambios que necesita, pero otros Embedded pueden estar realizando otros cambios en las mismas páginas.

Ejemplo:

Un proceso Embedded necesita una nueva página para guardar en ella los datos de la tabla PRODUCTOS, esa nueva página tiene el número 5.000

Otro proceso Embedded necesita una nueva página para guardar en ella los índices de la tabla VENTAS, esa nueva página también tiene el número 5.000

No olvides que cada proceso cree que tiene acceso exclusivo a la Base de Datos y por lo tanto desconoce lo que otros procesos le están haciendo a esa Base de Datos. Un Embedded no tiene forma de saber que otro Embedded está accediendo a la misma Base de Datos.

En algún momento el problema se vuelve catastrófico, cuando una página TIP se convierte en una página de cualquier otra cosa y se perdió el acceso a todos los datos.

Desastre total.

Conclusión:

Si más de un usuario accederá a una Base de Datos de Firebird al mismo tiempo, entonces debemos usar una arquitectura Classic, SuperClassic, o SuperServer para ello.

Podemos usar Embedded cuando estamos 100% seguros de que solamente un usuario se conectará y jamás, por ningún motivo, se conectará más de un usuario.

Si ponemos a una Base de Datos en una carpeta compartida de la red y permitimos que accedan a ella usando Embedded es seguro que en algún momento esa Base de Datos se volverá totalmente inservible.

Artículos relacionados:

Entendiendo a las páginas de la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

 

 

Anuncios