Cómo comenzar con Firebird

[mamaro]

Ampliando un poco lo de Delfino, te digo que el archivo "FBCLIENT.DLL" debe estar en "C:\windows\SYSTEM" para win95/98, "C:\winnt\system32" para win2000, y "C:\windows\system32" en Win XP.

Creo que la librería también puede estar en el directorio de tu ejecutable, pero ésto realmente no lo probé.

[malcomp]

Empezado por mamaro

Ampliando un poco lo de Delfino, te digo que el archivo "FBCLIENT.DLL" debe estar en "C:\windows\SYSTEM" para win95/98, "C:\winnt\system32" para win2000, y "C:\windows\system32" en Win XP.

Creo que la librería también puede estar en el directorio de tu ejecutable, pero ésto realmente no lo probé.

En efecto, el archivo estaba en ese directorio. Pero sigo sin conseguir crear la base de datos. Durante la instalación, estaban las 4 casillas marcadas, y del isql, uf... mucho para mí todavía....

[[brakaman]]

Hola amigo:

Ideas....
Si antes habias instalado alguna version de Interbase debes desinstalarla por completo, en el directorio windows\sysem32\ que no exita un fichero gds32.dll (o algo asi)

Luego desinstala Firebird y vuelve a instalar el motor asegurandote que la libreria fbclient.dll esta en el directorio Windows\system32

A partir de ahi arranca el servidor y ejecuta el IBEXPERT . (Lo siento no he utilizado el Flamerobin pero sera similar , creo)

Utiliza la base de datos de ejemplo de Firebird....
Ruta C:\Archivos de programa\Firebird\Firebird_2_0\examples\empbuild\Employee.fdb

registrala y conectate, deberia de funcionar.

Animo.

[malcomp]

eeeeeeeehhhhhh ! ! ! !
vamos mejorando....
Hice todo lo recomandado por brakaman.
Pero usé el FlameRobin. Me pude conectar a la base de datos de ejemplo de Firebird, pero cuando intenté abrirla, ahora me dice que el password y la contraseña son incorrectos....

¿Cuáles serían estos datos?

UNa vez más quiero agradecer a todos por la ayuda.
Sin duda que este foro será muy útil para todos quienes estamos partiendo en esto, porque yo creo que todos los problemas que pueden ocurrir al iniciarse, me han sucedido a mí.... jajajajajaja

[malcomp]

Empezado por malcomp

eeeeeeeehhhhhh ! ! ! !

¿Cuáles serían estos datos?

Para que vean que si estoy investigando por mí mismo y para todos aquellos que al igual que yo, algunas respuestas no son tan obvias:

username : SYSDBA
password : masterkey

jijiji

[malcomp]

Bien.
Ahora volví a Delphi, y puse algunos controles en el formulario principal:

tIBDatabase, tIBTransaction y tIBTable.

Están todos conectados entre sí. Puedo ver las tablas de la base, y los nombres de los campos.

Ahora ando buscando un control tipo DBGrid, que me permita simplemente ver los datos de la tabla en la pantalla.

[[egostar]]

Son los componentes Standard DBGrid y DataSource, que se encuentran en las carpetas Data Access y Data Controls

Salud OS.

[malcomp]

Aquí vamos de nuevo con otra pregunta.

Cuando deseo ocupar un control que muestre datos de una tabla, (Grid, ComboBox, etc.) ¿Siempre se deben crear objetos IBDataBase, IBTransaction IBTable e IBDataSource?

Saludos.

[[Delphius]]

Empezado por malcomp

Cuando deseo ocupar un control que muestre datos de una tabla, (Grid, ComboBox, etc.) ¿Siempre se deben crear objetos IBDataBase, IBTransaction IBTable e IBDataSource?

Hola malcomp,
La respuesta es SI.
Esos componentes son los que en verdad acceden a la base de datos. Sin ellos no podrías comunicarte con la base de datos.

Puedes "manejar" a esos componentes de tres maneras:
1. Dejarlos creados en tiempo de diseño con algunas propiedades con algún valor por default.
2. Crear los componentes bajo demanda, en tiempo de ejecución. Es decir que cuando sea necesario crearlos, usarlos y al finalizar la operación liberar la memoria.
3. Emplear un Módulo de Datos. Que es como un "formulario" en donde puedes colocar los Datasource, los transaccion, database, querys... Con esto consigues tener todo lo referido a "base de datos" en un solo lugar en vez de estar dispersando por todos lados los componentes.

Saludos,

[malcomp]

Delphius:
Estuve revisando las bases de datos de DEMOS de Delphi, y justamente la opción 3 es la que usan en una de ellas.
Me pareció la mejor, ya que con un solo formulario, tienes todo disponible para el resto de las aplicaciones.

En este momento estoy desarrollando una aplicación pero como estoy en período de aprendizaje con este tema, creo que probaré distintas opciones, y ahí veo cuál me acomoda más, pero por ahora, me gustó mucho la 3.

Gracias y saludos.

[[Delphius]]

Hola malcomp,

Empezado por malcomp

En este momento estoy desarrollando una aplicación pero como estoy en período de aprendizaje con este tema, creo que probaré distintas opciones, y ahí veo cuál me acomoda más, pero por ahora, me gustó mucho la 3.

Tu experimenta... y usa la que más te resulte cómodo.
Aunque la opción 1 es la más fácil de emplear (y por lo general la primera que se estudia) tiene un defecto muy grande: estarás mezclando la interfaz con la capa de acceso a datos. Lo cual lleva a una mayor dependencia entre la interfaz y la base de datos.

La opción 3, en cambio, que a mi modo de ver y entender, es la más recomendable. Ya que el canal de comunicación entre la interfaz y la base de datos es más delgado, mucho más "modular" (por ponerle un nombre).

La implementación de los módulos de datos es una extensión de la segunda opción. Esto quiere decir que puedes crear/destruir (abrir/cerrar) varios módulos de datos de forma tal que consigas separar el "modelo de datos" en varios módulos más o menos independientes. Por ejemplo: supongamos que tu tienes 3 módulos: Clientes, Ventas, Compras. Cada uno tiene lo necesario para acceder a una PARTE de la base de datos. Esto te permite reducir memoria y trabajar solo con lo necesario según se necesite. Por ponerte otro ejemplo: quien tenga un permiso para cargar Compras, solo debe tener creado el módulo de compras (y el de la conexión)... ¿Para qué cargar con tantas cosas si solo a él le interesa compras?

La elección de como distribuir los módulos dependerá también de las necesidades de mantenimiento, de la complejidad del sistema y otros factores más... Por lo general, si se sabe que el sistema es grande, y complejo... crear los módulos por demanda es una muy buena opción.

A los fines de tu práctica... comienza con uno solo. Después sigue avanzando.

Saludos,

[malcomp]

Empezado por Delphius

Tu experimenta... y usa la que más te resulte cómodo.

Según mi forma de ver, también la 3 es la mejor.

Por ahora, tengo otra pregunta.
En access, existe un atributo que se le puede agregar al campo Clave Principal, que hace que los valores se generen automáticamente de forma incremental. Se llama AUTONUMERICO.

¿Se puede hacer lo mismo con FireBird?