Firebird: IBDataSet ó IBTable
 

Estoy empezado con Firebird y delphi2009
Y segui el tutorial de TeraWiki para la conexion con firebird

Pero al querer configurar el IBDataSet me manda un error (Unable to determinate field names for IBDataSet1)
Pero al usar IBTable si puedo abrir la tabla sin problemas.

Quiero saber cual de los 2 componentes es mejor usar para un catalogo de ciudades donde voy a hacer altas edicion y bajas. Y si es el IBDataSet como resuelvo ese error

A ver, según entiendo yo, para mostrar tus datos necesitas un Dataset. Este dataset necesita un origen de datos, que puede ser un TTable o un TQuery (o incluso un TClienteDataSet).
Puedo estar equivocado, pero según yo, un TDataset por si solo no funcionaría.

Pues si pero estoy siguiendo las instrucciones del tutorial y me sale ese error

http://wiki.clubdelphi.com/wiki/index.php/Tutorial_Conexi%C3%B3n_con_Firebird_desde_Turbo_Delphi_(Parte_II)

ya, estoy confundiendo un dataset con un datasource, mil disculpas.

Si usas un IBDataSet, debes configurar sus propiedades SelectSQL, RefreshSQL, InsertSQL y UpdateSQL,
mediante el DataSet Editor (boton derecho sobre el componente) o directamente a mano le pones las sentencias SQL.
Despues con la opcion Fields editor, agregas los campos de la select como persistentes.

La principal y fundamental diferencia entre estos dos componentes, es que el tIBTable cuando se abre, se trae TODOS los registros de la tabla, mientras que el tIBDataSet se trae sólo los registros que cumplen la condicion de la select, con lo que da muuuucho más juego que el tIBTable.

PD: Aunque lo más sencillo sea usar tIBTables, en un entorno cliente-servidor, este tipo de componentes debería estar prohibido usarlos.

El DataSet trae muchas ventajas como dice defcon1_es, por ejemplo yo siempre para crear las sentencias en el selectSQL primero pongo algo como:

Código SQL [-]
    select * from PermisosXPerfil

Esa tabla tiene 3 campos, id, idPermiso, idPerfil, si yo veo esto en un DBGrid es algo como:

Si vemos, esos datos no son muy dicientes, entonces, yo cambio el selectSQL pero antes de cambiarlo uso el DataSet Editor para crear las sentencias insert, update, delete y refresh, ya que estos son los campo que voy a trabajar

Código SQL [-]
update TPERMISOS_PERFIL
set
  ID = :ID,
  IDPERMISO = :IDPERMISO,
  IDPERFIL = :IDPERFIL
where
  ID = :OLD_ID

Código SQL [-]
insert into TPERMISOS_PERFIL
  (ID, IDPERMISO, IDPERFIL)
values
  (:ID, :IDPERMISO, :IDPERFIL)

Código SQL [-]
delete from TPERMISOS_PERFIL
where
  ID = :OLD_ID

Código SQL [-]
Select 
  CODIGO,
  PERFIL,
  PERMISO
from TPERMISOS_PERFIL 
where
  ID = :ID

Ahora si cambio el selectSQL por:

Código SQL [-]
select pp.*, pm.NOMBRE PERMISO, per.NOMBRE perfil from TPERMISOS_PERFIL pp
left join TPERFILES per on per.ID = pp.IDPERFIL
left join TPERMISOS pm on pm.ID = pp.IDPERMISO
where pp.IDPERFIL = :IDPERFIL
order by pp.IDPERMISO

Así tengo un resultado con menos registros, más datos para mostrar por registro y más entendible:

No si antes de abrirla estableces una condición en su propiedad Filter y pones su propiedad Filtered en True. ;)

Aunque ya no uso IBX por sentirme más completo con dbExpress, hay que reconocer esa particularidad del componente TIBTable, que a diferencia de otros XTable, usa el valor de la propiedad Filter como condición Where de una sentencia SQL Select que ejecuta para abrir el cursor (internamente hace algo como "Select * From Tabla Where Filter").

Por tanto, usar un TIBTable con las propiedades Filter y Filtered debidamente establecidas puede resultar en muchos casos tan eficiente como un TIBDataSet.

Claro que con un TIBDataSet o un TIBQuery se extienden las capacidades, dando mucho más flexibilidad para armar las sentencias SQL, pero no como para "prohibir" a raja tabla (valga la expresión) el uso del TIBTable.

Un abrazo filtrado.

Al González. :)

Esa propiedad Filter es muy buena y en migraciones de información de Paradox a Firebird es muy útil ya que muchos usaban las tablas (para rematar abiertas todas todo el tiempo)

Lo suyo es usar unicamente el TIBDataset, y rellenar solo la propiedad SelectSQL si se quiere solo una query, y las otras si se quiere poder editar los datos.
Siempre uso el dichoso select * from tabla en ambiente cliente servidor sin ningun problema, el componente tiene la propiedad BufferChunks q trae solo los 1000 primeros, y ademas el DBGrid trae solo los necesarios para mostrar en la pantalla..

Gracias a todos, me quedo con TIBDataset, por lo que comentan estos tienen mucha libertad para crear consultas y edicion, sobre todo edicion directa sobre un DBGrid.