Consejos para empezar con firebird

[[RONPABLO]]

el embebido es bueno, y ademas ayuda mucho el no tener que preocuparse porque el servidor de firebird no este corriendo, lo unico malo es que solo permite que una aplicacion se conecte simultaneamnete con el... pero en si... cuando lo necesites, pues simplemente montas el firebird SS o SC y listo, con las MDO aun no he trabajado, solo una vez las vi y son muy similares a las IBX, por ultimo un consejo que descubri con el tiempo... crea un DataModulo donde tengas todos los DataSets, todos los Querys y Coneccinoes, Transacciones y en si todo lo que se refiera del manejo de datos (es mas dentro de ese modulo crear procedimientos tales como guardar(consulta :TMDOQuery) donde mandas como parametro el dataset o la consulta que quieres le aseguro que ayuda mucho y ahorra dolores de cabeza..

[[Lepe]]

Empezado por RONPABLO

por ultimo un consejo que descubri con el tiempo... crea un DataModulo donde tengas todos los DataSets, todos los Querys y Coneccinoes, Transacciones

Depende de la filosofía que se quiera adoptar. Normalmente una ventana solo se abre una vez y despues se cierra, en ese caso tu filosofía es acertada.

Imagina que quieres 2 ventanas de clientes abiertas al mismo tiempo, una para modificar y otra para consultar datos de otro cliente, para copiar y pegar, etc. En este caso, si todas los MDODATASETS estan en el Datamodule, al moverte desde una ventana de Clientes, la otra ventana sigue los movimientos, porque comparten el mismo Dataset, al poner en Insertar una ventana, la otra tambien se pone. Obviamente en este caso, es necesario tener los MDODATASETS cada uno, en su Ventana, para que sean datasets independientes.

Te doy la razón en que siempre es bueno tener un Datamodule para situar el MDOTransaction y el MDODatabase, amén de esas rutinas auxiliares que comentas.

Saludos

[roman]

Pero entonces, ¿dónde queda la independencia entre la interfaz visual y el acceso a datos? Entiendo lo que quieres decir pero quizá sea entonces cuestión de adoptar otra ruta. Por ejemplo, no es tanto una cuestión de que todos los dataset estén en un mismo data module, es más bien el hecho de que estén separados de los formularios, aun cuando sea en varios módulos. Se podría, por ejemplo, usar un data module para los Clientes y, formulario que lo requiera, crea una instancia de ese data module. Así, puedes tener dos ventanas de Clientes por que cada una apunta a una instancia distinta del mismo data module.

// Saludos

[[Caral]]

Hola seoane
Despues de ver esto estoy un poco :

una amiga necesita organizar su trabajo (pedidos, fechas de entrega, etc ...) y me a preguntado si le podía hacer algo sencillo.

Voy a dar mi opinion, ya se que van a sonar todas las campanas, pero aun asi lo voy a hacer, de alunno a maestros.
No conozco bien Firebird, pero si veis por el foro encontareis que hay mas dudas que respuestas, a mi forma de ver cuando se quiere hacer algo sencillo que te lleve un par de horas, totalmente funcional, yo usaria Access, ya sonaron las campanas!!!??? , Lo se, limitantes, pero nada inalcanzable, trabajo con access en mi negocio, tiene mas de 800m, lo tengo ligado a MySql por si acaso, y no tengo ningun problema, es mas hasta por internet lo manejo,(me enseñaste tu a hacerlo ),es mi humilde opinion.
Crear bases de datos por codigo, enlazarlas via tal o cual modo, muy bonito, aprenderas mucho, pero de simple y sencillo nada de nada.
Te aseguro que con tu experiencia te sientas delante del ordenador y en una hora tienes un programa que haga lo que tu amiga necesita.
Ya se que vendra el chaparron, pero me agunto.
Saludos Maestro

[Kenobi]

Al igual que Caral con toda humildad digo o pregunto, porque firebird(ojo que ni lo conozco ni visto asi que habla la ignorancia)porque no MySql 5 que segun es muy bueno por otro lado eso que dijo Caral de tener ligado Access y MySql no se a que se refiere y porque usar dos manejadores juntos
en todo caso que tiene de especial firebird que usuarios bastante avanzados como ustedes lo usan ....


Gracias y disculpen el exceso de ignorancia...

[[RONPABLO]]

Porque Firebird?

1. Es la versión evolucionada de InterBase 6.0 (la cual fue Open Soure), cuando otras bases de datos estaban dando sus primeros paso (MySQL, Postrgres y hasta el SQL server que antes del 2000 era una... mejor no digo), Interbase ya estaba en el mercado con procedimientos almacenados trigers entre otras cosas.

2. Recursos. para mi es muy agradable que una aplicación que haga tantas cosas solo ocupe tan poco espacio en Disco y consuma tan pocos recursos, permitiendo trabajar en equipos que otros ya dan por obsoletos.

3. Tan rápido como MySQL pero con la diferencia de que solo maneja una sola tecnologia (MySQL tiene InnoDB (la cual ya la compro Oracle y que al usar esta se pierde esa gran velocidad de MySQL, y otras 3 0 4 mas que no recuerdo).

4. Soporte a bases de datos extremadamente grandes sin perdida de rendimiento (Casimiro nos mostraba alguna vez la noticia donde habían bds Firebird por el orden de los teras), SQL Server en la versión shareware no permite pasar a mas de 2G y una limitación de usuarios simultáneos (creo que son 6, no recuerdo mucho, porfavor me corrigen).

5. Una gran cantidad de componentes nativos en productos Borland (recuerda que Firebird es la evolución de Interbase 6, el cual es de la borland), que productos Dephi por ejemplo.

6. Es Open Source y Free Distribution con licencia Mozilla (que no es lo mismo a GNU).

7. Corre en varios sistemas Operativos, yo lo he usado desde win95 hasta vista y en Linux Red Hat, Mandrake y Debian (Red Hat y Debian fueron pruebas que me salieron muy bien en mandrake fue para un proyecto).

8. Permite conectar a .Net, ASP, PHP, Delphi, C Builder y otros muchos mas.

Como todo tiene defectos pero desde mis necesidades son desde muy lejos mas los pro que los contra

[[Lepe]]

MySql, según dice su propia licencia, puedes vender tu programa, pero tienes que entregar el código fuente con él, si no lo haces debes pagar una licencia de 600 €.

Firebird es totalmente gratuito y OpenSource.

El hecho de que haya más preguntas que respuesta en el foro de Firebird, es bien obvio. La gente viene a hacer sus preguntas antes de mirar los manuales... porque estan en inglés. Si eres o quieres llamarte programador, el inglés tienes que manejarlo, por lo menos leer y comprender, (no hace falta pronunciar bien).

Como ya dije en otro hilo, en mi mes de vacaciones me leí unas 1.500 páginas de los manuales de Interbase, no necesitas nada más, quizás, alguna pregunta por "falta de experiencia", pero no tienes que saltar al foro a preguntar por el NETFILEDIR de paradox. Los manuales te dicen todo lo que necesitas saber. Lo aprendes de primera mano, rápidamente y siguiendo un hilo que tiene un objetivo. En el foro se responden dudas concretas, pero no se puede explicar "Todo".

Las maravillas de Firebird Vs Access podrían ser (desde mi punto de vista):
- Los SP, esos grandes desconocidos. Equivalentes en Access a pedir una consulta, recorrer los datos (en delphi) de esa consulta, haciendo cálculos, añadiendo campos LookUp, realizando sumas, etc, y aplicando filtros personalizados. Con Firebird, lo haces en la BBDD, después usas un simple TQuery con "Select * from NombreStoreProcedure(parametro entrada)"

- Informar a todos los ordenadores de una red de la inserción de un nuevo cliente, factura, etc. En access usas un Timer para refrescar los datos cada X segundos. En Firebird, al insertar un nuevo cliente, el servidor informa a todos los ordenadores, y simplemente tendrás que cerrar y abrir las consultas. Es algo más eficiente ¿no?

[roman]

En mi opinión, en este hilo se está perdiendo un poco la perspectiva de lo que originalmente se preguntó y se pone a FireBird como la solución única para cualquier situación.

Se les olvida que FireBird tiene una curva de aprendizaje bastante mayor que otros sistemas:

Empezado por Lepe

en mi mes de vacaciones me leí unas 1.500 páginas de los manuales

¡Mil quinientas páginas! ¡Y en vacaciones! ¿¡Para hacer una agenda!? ¡UNA AGENDA!

¿Para qué quiero procedimientos almacenados, disparadores y quién sabe cuantas cosas más para hacer una agenda?

No estoy diciendo que no haya que aprender FireBird, pero como bien dijo Caral

Empezado por Caral

Cuando se quiere hacer algo sencillo que te lleve un par de horas, totalmente funcional, yo usaria Access

No me cabe la menor duda que quien inició este hilo tiene capacidad más que sobrada para aprender FireBird (u Oracle si me apuran), y hacer su agenda con ello, pero creo que no es necesario siempre matar pulgas con cañones.

Tanto las respuestas de RONPABLO como de Lepe, son muy interesantes, y ambas dan un buen panorama de lo que es y puede ser FireBird; pero no estamos hablando en general ni tratando de encontrar la solución última para cualquier sistema. ¿Que MySQL obliga a dar el código fuente? Cierto, pero, ¿para una agenda de una amiga, es esto terrible? ¿Que MySql se alenta con tablas InnoDB? Cierto, pero esto sólo ocurre con inserciones y actualizaciones masivas y no sería el caso ni para una agenda ni para muchas aplicaciones.

En fin, es sólo una opinión. No pretendo descalificar las otras, sino simplemente mantener en perspectiva las cosas.

// Saludos

[[egostar]]

Hola de nuevo después de un largo fin de semana (ayer lunes fue día de asueto en México) en el cual me olvidé de todo, de cualquier contacto con mi computadora, de internet, de mi correo, de todo....., bueno, no de todo.

Quiero complementar lo dicho por Roman, sin lugar a dudas, una agenda se puede hacer hasta con Paradox (lo prefiero a Access), pero, si nos ponemos un poco pesados, hacerlo con firebird me parece una buena opción, de hecho yo estoy desarrollando una agenda (tambien para una amiga.... vaya, se me hace que se hace moda eso de agendas para las amigas).

Bueno, la cuestión es que después de haber terminado la agenda, a mi amiga se le ocurrió que con la agenda pudieramos generar muchas mas cosas, es decir, el llamado ToDo, generar documentos como contratos, invitaciones, etc... ya que la agenda proporciona la información relativa a sus contactos.

Desde un inicio decidí hacerlo con Firebird, y no por otra cosa sino para aprender a usarlo, yo siempre hice sistemas con Paradox, cosa que me viene muy bien ya que como ha dicho Caral, los sistemas que hago son muy sencillos y bastaba con mi base de datos por excelencia.

Ahora, Firebird y su curva de aprendizaje si tiene su tiempo, pero he visto que me permite cosas en las que Paradox requiere de mayor esfuerzo, por ejemplo su uso local o en red sin tener que batallar con el BDE entre otras cosas.

En concreto, quiero decir, que para aprender a usar firebird (o cualquier otra base) no hay como una aplicación que no es de misión crítica donde te puedes dar el lujo de cambiarla si no es lo que habias pensado.

Desde mi punto de vista, claro esta.

Saludos.