19 replies to this topic

[Delphius]

Buenas, estoy dando forma a una aplicación para varios clientes y mientras estudiaba en como encarar el DER se me encendió la lámparita de dudas.

Mi aplicación es más del tipo monousuario, por lo que emplear una versión embebida quizá sea lo más adecuado, y entonces me dije... ummm si alguien ya tiene instalado Firebird me la lía parda. Recuerdo que ya algo de esto se debatió en este hilo. Vagamente recuerdo haber leído en algún sitio (que ya no localizo) que había una manera de configurar a firebird para que pueda trabajar tanto en modo server como la embebida en simultáneo.

 

Luego me digo bueno... una forma de evitar esto es que instale la versión server y haga uso de esta ya sea en LAN o localmente no me jode. Pero esto elimina los problemas... sigue el planteo: ¿Y si ya tiene una versión, DISTINTA, de Firebird?

Desde la versión 2.1 Firebird fue diseñado para soportar múltiples instancias y las cosas son relativamente más sencilla y hasta donde recuerdo ya Firebird hace las verificaciones. Pero para versiones más tempranas hay otras formas de hacerlos, y una forma "genérica" de conseguir instalar varias instancias desde 1.5 en adelante  es más engorrosa.

 

Me preguntaba entonces si quizá no sea mala idea directamente atacar el problema de otra forma: en lugar de lidiar con multiples instancias ¿Porqué no ofrecer con mi sistema la posibilidad de disponer versiones de una misma base de datos en diferentes versiones? Luego bastaría con detectar si hay algún Firebird instalado, detectar que versión emplea y configurar la aplicación para trabajar con ésta.

Pero claro, esto tampoco es una solución super elegante ya que es más esquivar la bala pero no al atacante. No sólo eso sino que además emplear el modo server ya es emplear un cañón cuando con la pistola basta, pero bueno... tampoco es un gran pecado ¿O si?

 

 

La gran gozada, para mi como para mis clientes, es que el sistema pueda trabajan con la versión embebida, y que incluso pueda lidiar con una posible instalación de Firebird en cualquier versión.

Por ello, me preguntaba que maneras de lidiar han implementado ustedes, y/o que alternativas proponen.

 

Saludos,

[cram]

Digo no, ¿por qué? no especificar requisitos para correr la aplicación, ya que esto de determinar la versión del motor, etc. se me hace algo poco sencillo y no creo que sea interesante como solución dado el costo y bajo beneficio.

En cuanto a trabajar con dos formas de conexión, es fácil (en teoría). Podrías tener ambas versiones y manejarte con una u otra con alias diferentes que se selecciones en el programa.

 

Saludos

[Delphius]

Disculpa cram que pregunte, ¿A que te refieres con versión? ¿Hacer que el sistema use Server y que funcione en modo local o LAN? ¿Y por requisito tu idea es condicionar a que use por ejemplo FB 2.5 ya sea en cualquier arquitectura que yo defina? No pillo tu idea.

Saludos

[Agustin Ortu]

Marce, si se permiten alternativas fuera de Firebird, y realmente tu aplicacion es del monousuario y local, yo consideraria fuertemente usar una base SQLite

El problema es que como yo no juego en la cancha de lazarus no se si desde ese terreno tienen acceso a SQLite. Pero te ahorrarias miles de dolores de cabeza

Ahora, si necesitas multi-usuario, conectividad en red local, no sirve de nada

[Delphius]

Marce, si se permiten alternativas fuera de Firebird, y realmente tu aplicacion es del monousuario y local, yo consideraria fuertemente usar una base SQLite

El problema es que como yo no juego en la cancha de lazarus no se si desde ese terreno tienen acceso a SQLite. Pero te ahorrarias miles de dolores de cabeza

Ahora, si necesitas multi-usuario, conectividad en red local, no sirve de nada

 

Admito que en un momento pensé en SQLite. Pero como es un desconocido para mí, lo dejé de lado.

No se hasta que punto tiene sus limitantes (como ser capacidad de hacer backups, tamaño del archivo, triggers, procedimiento almacenados, vistas, etc).

 

Lo estuve meditando un buen tiempo y no veo que la aplicación merezca o sea tan importante que sea cliente-servidor. Para el propósito y uso es más de carácter monousuario. Se que SQLite va bien justo con el monousuario. Hay una remota posibilidad de el enfoque cliente-servidor pueda ser útil y es que algún cliente tenga un estudio formado por varios socios y comparten entre si algunos trabajos. La amplia mayoría de mis potenciales clientes trabajan en solitario aún cuando existen trabajos en común con otros profesionales, o al menos eso tengo entendido.

Pero claro... desconozco el "ambiente" de trabajo de cada uno, y vaya a saber que más tienen instalado en sus oficinas... justo por eso es que me quería proteger ante la remota posibilidad (pero que de darse tiene un buen impacto) de que en sus equipos ya tengan algo que use Firebird.

 

¿SQLite es tan simple como se dice, que basta con poner una dll en el mismo directorio de la aplicación y no hay choque de versiones? ¿Tiene potencial como triggers, SP y vistas?

 

Tengo entendido que Lazarus si soporta SQLite.

 

Saludos,

[Agustin Ortu]

Yo hace poquito libere una aplicacion monousuario que utiliza SQLite. Hoy por hoy casi se podria poner las manos en el fuego que cualquier sistema operativo tiene ya su sqlite3 incluido. De windows 7 para arriba por lo menos si. Y de ultima distribuis la bliblioteca sqlite y listo. Para el caso Delphi, es menor preocupacion porque FireDAC mete la dll en el ejecutable (como si fuera la midas) y te olvidas de todo

 

La verdad que para mi fue un gustazo como decis arriba porque nuestra aplicacion ERP principal trabaja sobre sql server y es un dolor de terlipes el tener que instalar el motor en los equipos. Ademas como pesa sus ~300 mb no es algo que se pueda distribuir facilmente, la instalacion no puede ser desatendida (silenciosa, como si se puede en firebird) ya que de hecho hay que hacer algun chanchullo para que ande bien. Por ejemplo, el paquete para instalar sql server 2008 R2 (el que usamos nosotros), en su version español, debido a un fallo de M$, hay que modificar la config de idioma y region del equipo y poner España.     

 

En fin, no quiero irme mas aun por las ramas, 

 

Con respecto a los triggers, vistas y stored, yo la verdad nunca los uso. El unico momento que utilizo triggers es en el caso de los generadores. Vistas nunca use, stored menos... ya que es "casarse" con la BD y yo soy feliz con Object Pascal. No me gusta la programacion del lado de la BD. Es mas dificil de depurar, estas atado a otro lenguaje (el de M$ es horrible realmente)

Todas esas cosas prefiero controlarlas desde la aplicacion Delphi. Aunque es cierto que esto es una degradacion de la performance.
 

Realizando una busqueda rapida en San Google, parece ser que SQLite soporta:

-  Views: https://www.sqlite.o...createview.html

- Triggers: https://www.sqlite.o...atetrigger.html

 

Pero no SPs 

 

Con respecto a los backup: http://stackoverflow...sqlite-database

 

Parece que tiene una interesante API: http://sqlite.org/backup.html

 

 

PD: Por cierto, fantastica la funcion de autoguardado del foro, habia perdido todo lo que habia escrito

[Delphius]

Gracias por tu compartir tu experiencia Agustín.

Es una lástima lo de SPs. Para mi sería un plus, aunque entiendo también el punto que siendo monousuario y para ganar algo de velocidad y prestación que exista SPs no es algo tan primordial.

 

No se si es que estuve leyendo mal, pero parece que SQLite tiene un pequeño escollo con las fechas/horas. Tendría que probar como funciona bien esto de que SQLite "transforma" y almacena las fechas en texto o en enteros según como uno lo establezca y en que me afecta en Lazarus (o al menos en como lo interpretarán las suites de componentes, si es que se toman el trabajo de hacer la equivalencia al respectivo TDateTime).

¡Mi aplicación es altamente basada en operaciones de fechas y horas!

 

Saludos,

[Agustin Ortu]

Bueno ese tema de los datetime no lo habia pensado. Como te decia, desde Delphi todo eso esta "facil" gracias a Dios. Por defecto, te almacena la fecha como string, pero desde la aplicacion seguis trabajando con DateTime. Luego, FireDAC se encarga de hacer el mapeo. Le podes mandar hasta SQL con BETWEEN entre dos fechas y anda al pelo. 

 

Con respecto a performance, yo te diria que SQLite si no es el mas rapido esta ahi. Justamente, al perder tantas caracteristicas "importantes" es en donde gana velocidad.

 

Por ejemplo: Existe la posibilidad de que el archivo SQLite se pueda compartir entre dos aplicaciones. Aunque no es lo recomendado, pero poder se puede. Al hacer eso, la performance baja mucho. Si configuramos la conexion a SQLite para que sea lo mas monousuario posible (esto es, bloqueo total del archivo; desde afuera, no entras ni para ver, asi de sencillo ) se vuelve en una bestialidad de rapido. Pero donde metes concurrencia en la ecuacion, es para considerar ya otra alternativa

 

En realidad, SQLite tiene una implementacion bastante particular de como almacenar los datos. Los "tipos" soportados son "pocos". Y existe algo llamado column afinity si mal no recuerdo, en la que basicamente, se "da cuenta" de cual es la mejor forma de guardar la informacion

 

Aqui esta mejor explicado: https://www.sqlite.org/datatype3.html

[Nikolas]

Te voy a responder desde otro lado:

 

Las pequeñas y medias empresas no suelen cambian de PCs, entonces no deberian cambiar de programas, en este caso puntual "la version de firebird".

Mi socia que tiene 35 años en el rubro aun tiene clientes que corren sus sistemas en DOS. (hechos en clipper)

 

Las empresas de desarrollo de sistema, no trabajan con Firebird, por lo que seria un caso muy raro que te encuentres con una version instalada.

 

Yo no perderia mucho mas tiempo y trabajaria con Firebird 2.5. con cualquier de sus versiones (Emb o Srv).

[Agustin Ortu]

Hasta que te topas con un tipo que atendimos nosotros

[Nikolas]

Hasta que te topas con un tipo que atendimos nosotros

 

claro o uno mio. En tal caso, no deberia importar la version que antes habia porque "parece" que se va a reemplazar.

[Delphius]

Muchachos, ya me hacen dudar   

 

Estuve explorando la posibilidad de SQLite, y hay operaciones que me agradaría resolver via SP cosa que con él no se puede. Por ello ya me tiro a la pileta por emplear Firebird 2.5 en su versión server directamente. Con esto puedo trabajar cómodo, y al menos al ser server me evito lidiar con un conflicto emb vs server. Y en caso de haber otra instancia ya me las arreglaré cuando aparezca uno

 

Saludos,

[Agustin Ortu]

claro o uno mio. En tal caso, no deberia importar la version que antes habia porque "parece" que se va a reemplazar.

 

 

Con el nosotros me referia a la comunidad Delphi

 

Marce: https://firebird21.w...ma-computadora/

 

A ver si te sirve eso (lo lei al tun-tun)

 

De todos modos me parece que resolviste bien; el estar pensando "y que pasa si..." se me viene a la mente "programar defensivamente"

 

Si aparece el maldito con el firebird instalado ya te las vas a arreglar. De ultima te haces un programita que detecte si esta instalado en el equipo y chau

[Delphius]

¡Gracias Agustín por el dato!

Hoy mientras estaba haciendo algunos trámites por la mañana estaba pensando en hacer que la propia aplicación en su primera ejecución analice si hay en el equipo un FB instalado. O la otra como dices, disponer una 2da aplicación a modo de instalador que haga esto y configure todo.

 

La técnica más KISS que imaginé es hacer todo considerando el escenario positivo y no evaluar nada. Y si el cliente propesta, ¡pues a darle soporte y cobrarle más $$$! Pero cuando recuerdo el tipo de clientes que tengo, necesitan el modo más friendly y el que menos intervención les de y eso me lleva a una programación más analítica.

 

Saludos,

[Marc]

Hola, llego un poco tarde a este hilo

 

Si consideras una opción válida a SQLLite, entonces también deberías considerar como opción válida a Firebird Embedded (el motor empotrado).

 

Incorporar Firebird Embedded a tu aplicación (es una DLL que se pone en la misma carpeta de tu aplicación) significa que no te importa si hay algún Servidor Firebird instalado, puesto que no lo vas a usar y tampoco vas a interferir con él. Es la solución más simple posible, te puedes olvidar completamente de lo que ya haya instalado en ese equipo, y tienes acceso a toda la funcionalidad de Firebird (procedimientos almacenados, triggers, ... ....).

 

La ventaja de Firebird Embedded es que exactamente la misma base de datos te puede correr en un Servidor completo, de manera que si en ese lugar necesitas en el futuro acceder desde varios ordenadores, entonces en cualquier momento puedes poner un Servidor Firebird y pasar a trabajar de forma Cliente-Servidor con el mismo archivo de datos que venías corriendo en el Firebird empotrado.

 

O sea que inicialmente puedes poner la aplicación con Firebird Embedded, olvidándote de problemas de incompatibilidades con software ya instalado. Y si en el futuro necesitas acceso desde más equipos, pues entonces ya pones el Firebird completo y mueves la base de datos a ese Servidor Firebird (el archivo lo puedes mover tal y como está, no hay que hacer ni siquiera un Backup/Restore, el archivo de datos es exactamente igual ya se acceda desde un Firebird empotrado o completo).

 

Por cierto, tu aplicación podría funcionar perfectamente con distintas versiones de Firebird (póngamos por ejemplo: FB 2.0, 2.1 y 2.5). Para ello simplemente tienes que utilizar el mínimo común denominador, es decir no utilizar ninguna característica de las versiones más avanzadas de Firebird. La única dificultad estaría en distribuir la base de datos cuando haces una instalación, puesto que tienes que aplicar la base de datos correspondiente al servidor Firebird que haya instalado. Para ello veo dos soluciones: la primera es construir la base de datos desde cero mediante un Script (de esta forma se generará una base de datos correspondiente a tu versión), y la segnda forma es distribuir un Backup Transportable de la base de datos, hecho con la mínima versión que vayas a soportar (por ejplo FB 2.0), de esta forma, para instalar la base de datos lo que tienes que hacer es restaurar esa copia, con lo que se generará una base de dates acorde a tu versión instalada de Firebird.

 

Saludos.

[cram]

Marc, tarde... y yo que escribí algo y nunca apareció... estoy bastante harto de la conexión que tengo. A veces tengo que escribir en el bloc de notas y luego copiarla. 

Según leí, acabas de dar todas las respuestas de una pasada.

No inicié el tema, pero aprovecho tu conocimiento. Muchas gracias.

 

Ahora, pregunta, ya que jamás pude hacer funcionar un FB embedded. ¿siempre debe funcionar con TCP? al menos eso entendí.

 

Saludos

Edited by cram, 16 October 2015 - 10:18 AM.

[Marc]

Marc, tarde... y yo que escribí algo y nunca apareció... estoy bastante harto de la conexión que tengo. A veces tengo que escribir en el bloc de notas y luego copiarla. 

Según leí, acabas de dar todas las respuestas de una pasada.

No inicié el tema, pero aprovecho tu conocimiento. Muchas gracias.

 

Ahora, pregunta, ya que jamás pude hacer funcionar un FB embedded. ¿siempre debe funcionar con TCP? al menos eso entendí.

 

Saludos

 

No, el Firebird Embedded no funciona por TCP, solo funciona para conexiones locales. Es muy simple de utilizar, simplemente hay que poner la librería del Firebird Embedded como librería cliente de tu conexión a datos y ya te sirve todas las bases de datos locales a las que conectes.

 

Es decir, el fbembed.dll (el firebird empotrado) lo renombras a fbclient.dll o gds32.dll (depende del archivo cliente que busque tu aplicación), lo pones en la carpeta de tu aplicación para asegurarte de que ese es el archivo que tu aplicación abrirá al estableder la conexión, y ya está. Ya solo tienes que establecer una cadena de conexión local a tu base de datos. Ejplo: C:\Gestión\Datos\Gestion.fdb

 

Además de ese archivo, hay que copiar un par de Dll's más (para el runtime de C++, el soporte de cadenas internacionales, Udf's que quieras poder usar, ...). Te viene todo en el paquete que te descargas con el Firebird Embedded.

 

Si necesitas permitir accesos TCP entonces tienes que instalar el Servidor completo de Firebird. Pero es que realmente el acceso TCP es para acceder desde otras máquinas, en la red, por lo que es lógico que el servidor empotrado no esté a la escucha de ese puerto. Si quieres que otras máquinas de la red puedan acceder a la base de datos por la red, mediante TCP, simplemente se pone el servidor normal.

 

Una cosa buena del motor empotrado, es que puede actuar también como librería cliente para servidores Firebird completos. Me explico, tu pones tu motor empotrado como fbclient.dll de tu aplicación. Pues bien, si mediante esta librería cliente (el motor empotrado) te conectas a conexión local, entonces esa base de datos se abrirá y se servirá con el motor empotrado en tu aplicación, pero si la cadena indica una conexión TCP/IP entonces este fbclient.dll actúa como una librería normal y corriente, y redirige la conexión al servidor de la IP indicada.

 

Eso hace que la utilización sea muy simple. Tu instalas tu aplicación con el motor empotrado, pero si en un futuro quieras pasar a un servidor completo (para dar servicio a más ordenadores, ...) entonces solo tienes que cambiar la cadena de conexión y el motor empotrado actuará como una librería cliente normal. No hace falta que distribuyas más archivos o cambies archivos para pasar a trabajar en modo Cliente/Servidor, lo único que tienes que cambiar la cadena de conexión para que apunte a un Servidor completo de Firebird.

 

Me encanta trabajar de esta forma porque no necesita instalaciones, puedes tener tu aplicación con acceso a base de datos y todo, solamente copiando archivos. Es tremendamente cómodo que cuando un usuario te pregunta : "tengo que cambiar el ordenador, ¿ como instalo la aplicación en el nuevo ?", le puedas responder : "simplemente copia la carpeta tal y como está, y ya funcionará".

[Delphius]

Hola Marc, a pesar de no haber usado la versión embebida de Firebird se como se usa.

Lo que comentas me es conocido, pero quisiera sacarme una duda. Hasta donde tengo entendido, si en un equipo está instalado Firebird Server, y se desea disponer de una embebida (y de la misma versión) debe pararse el server para que pueda funcionar.

 

Saludos,

[Marc]

Hola.

 

Hola Marc, a pesar de no haber usado la versión embebida de Firebird se como se usa.

Lo que comentas me es conocido, pero quisiera sacarme una duda. Hasta donde tengo entendido, si en un equipo está instalado Firebird Server, y se desea disponer de una embebida (y de la misma versión) debe pararse el server para que pueda funcionar.

 

Saludos,

 

No, en absoluto, no es necesario.Hasta donde yo sé no hay ningún tipo de conflicto entre tu Firebird empotrado y cualquier Server que pueda haber instalado, incluso aunque sean la misma versión.

 

Y no veo como podría darse ese conflicto, puesto que tu aplicación conecta con la librería cliente, y si esa librería cliente ya es un servidor empotrado entonces se utiliza ese motor empotrado, con lo que nunca se busca un servidor completo y por tanto no debería haber conflicto aunque estuviera presente.

 

Así que el Firebird empotrado te va a funcionar siempre, haya o no haya la misma versión de servidor completo ya instalada.

[Delphius]

El proyectito de hoy me hizo recordar esto. Ya tengo confirmado el dato: entre embebido y servers no hay conflictos. Por lo que puede tenerse instalado cualesquiera y de versiones diferentes incluso.

Los recaudos que deben aplicarse pasan por cuando hay instancias de servers. Que como ya se ha dejado documentado en este hilo, hay formas de proceder a instalar más de una instancia en un mismo equipo. O bien, proceder a examinar si existe ya instalada alguna versión y ofrecer una edición de nuestras bases de datos adaptada y diseñadas para éstas.

 

En fin, que podemos dar por sentado este hilo. Y si alguien quiere documentar algo más es bienvenido.

 

Saludos,