34 respuestas en este tema

[Delphius]

Hola,

Sergio te agradezco por las aclaraciones  . Probaré las herramientas gratuitas para ver como andan.

Saludos,

[Sergio]

Sí, eso lo pierdo de gestionarlo a través de Firebird, pero con los ClientDatasets de Delphi consigo el mismo resultado con mucha menos carga para el Servidor.

Todos pueden modificar, pero el primero que graba es el que tiene éxito : se inicia otra minitransacción, se actualizan los datos en disco y se cierra la transacción.

Cualquier otro que intente grabar posteriormente esos datos, se va a encontrar con que el ClientDataset detectará que los datos en disco no son los mismos que él leyo y copió en memoria, y en lugar de actualizar los datos lanzará una excepción de Conflicto de Actualización (donde puedes mostrar una pantalla de Conciliación, mostrando la versión original del campo, tus cambios, la nueva versión en la base de datos de esos campos y escoger los que quieres que queden definitivamente).

Esto se controla mediante la propiedad UpdateMode del Provider del ClientDataset. Con upWhereAll todos los campos del ClientDataset tienen que tener aún el mismo valor, con upWhereChanged vas a poder grabar el ClientDataset si solo los campos que estás modificando mantienen el valor original, y con upWhereKeyOnly indicas que no te quieres preocupar por eso y que quieres grabar siempre los datos (independientemente de que otro haya hecho cambios mientras tú los editabas).

Marc, esto me interesa y bastante, ya que actualmente usamos FreeIB porque al ser componentes directos nos permiten jugar con la concurrencia, tipos de transaccion, etc., pero si hay otra forma mejor de hacerlo, me gustaria probarlo (estos componenetes que usamos huelen a muerto hace tiempo, los tenemos "parcheados" por nosotros para el dialect 3 y tienen un 3 o 4 fallitos molestos que no podemos/sabemos corregir y nos limitan bastante).

La estructura que tu usas, por lo que entiendo, es como si fuese un programa multi capa, pero con las dos capas en la misma applicacion: Tienes los ClientDataSet que son los que se muestran al usuario, pero conectan con un dbExpress que vive en la misma aplicacion, que son los que hacen esas mini transacciones.

Esto nos quitaria de encima los molestos FreeIB y nos permitiria incluso conectar con otros tipos de gestores de bases de datos tipo SQL Server.

Preguntas que tengo para ti:

1) Usais dos capas "reales" o teneis todo en la misma aplicacion?

2) dbExpress que tal van con FireBird? (si se pierden posibilidades respecto de una conexion "directa" tipo FreeIB, FIBPlus, etc)

3) Hasta que punto este enfoque es independiente de FireBird (tenemos un posible cliente que si no es con SQL server no quiere, el responsable de IT trabajaba antes en MS en los USA y los añora mucho?

4) Como es la estructura concreta de la aplicacion: En cada form (ficha, dbgrid, o lo que sea) supongo que teneis un ClientDataSet, pero ¿Cada ClientDataSet contra que conecta?

En su dia miramos los dbExpress pero no nos gustaron por un tema que no se si ya estara resuelto: Si haces un select * from tabla con FreeIB, y en tu grid se muestran 20 lineas, solo se "trae" del servidor FireBird las primeras 20 lineas, es decir, que las FreeIB se ocupan de pedirle al serivodr solo los record que relamente se muestran, mientras que los dbExpress se traen todos los record al ejecutarse.

Si los dbExpress no tienen ocion de traerse solos los records conforme se utilizan, tendriamos que plantearnos controlar eso desde programa, porque ahora usamos con mucha alegria select que se traen miles de record complejos SIN agobiar excesivamente al servidor ni quedarnos sin meoria (bueno, si pides un listado de esos datos, te quedas sin memoria, eso si).

[Marc]

Hola Sergio.

Marc, esto me interesa y bastante, ya que actualmente usamos FreeIB porque al ser componentes directos nos permiten jugar con la concurrencia, tipos de transaccion, etc., pero si hay otra forma mejor de hacerlo, me gustaria probarlo (estos componenetes que usamos huelen a muerto hace tiempo, los tenemos "parcheados" por nosotros para el dialect 3 y tienen un 3 o 4 fallitos molestos que no podemos/sabemos corregir y nos limitan bastante).

La estructura que tu usas, por lo que entiendo, es como si fuese un programa multi capa, pero con las dos capas en la misma applicacion: Tienes los ClientDataSet que son los que se muestran al usuario, pero conectan con un dbExpress que vive en la misma aplicacion, que son los que hacen esas mini transacciones.

Exacto .

Esto nos quitaria de encima los molestos FreeIB y nos permitiria incluso conectar con otros tipos de gestores de bases de datos tipo SQL Server.

Preguntas que tengo para ti:

1) Usais dos capas "reales" o teneis todo en la misma aplicacion?

No, yo utilizo solo una capa Delphi.

Me gusta pensar en mis aplicaciones, como aplicaciones de dos capas y media (que creo que dice Marteens). Con una capa de aplicación, otra de base de datos, y media capa de reglas de negocios en triggers y procedimientos almacenados de la base de datos.

Lo veo como mucha complicación innecesaria el añadir un capa de servidor de aplicaciones con las reglas de negocios. No sé si las ventajas compensan tanto trabajo.

2) dbExpress que tal van con FireBird? (si se pierden posibilidades respecto de una conexion "directa" tipo FreeIB, FIBPlus, etc)

Va de maravilla, pero ciertamente se pierden posibilidades, básicamente todo lo que es específico de Firebird y no genérico para cualquier base de datos SQL : no tienes componentes para capturar eventos de la base de datos, ni componentes para acceder al API de Servicios de Firebird (Backups, gestión de usuarios, ...).

Pero en la práctica no lo echo en falta. Los Backups los realizo llamando directamente desde mi aplicación al comando gbak.exe, la gestión de usuarios no la necesito ya que solo uso el usuario SYSDBA (después mi aplicación tiene sus propias definiciones de usuarios y de niveles de seguridad para la aplicación), etc. ... (además en Firebird cada vez están añadiendo que más opciones se puedan realizar directamente desde consultas SQL en lugar de recurrir al API de Servicios, como por ejemplo los nuevos comandos SQL para gestionar usuarios por SQL).

En realidad me pasé a FibPlus en mis últimas aplicaciones, y aún no he hecho nada que no hubiese podido hacer igualmente con dbExpress (sigo programando igual con ClientDatasets, por lo potente que es este componente). Un día de estos voy a hacer un buscar y reemplazar masivo de estas aplicaciones y cambiar todos los FibPlus por dbExpress de nuevo, ya que me estoy cansando de algunos bugs de FibPlus (son otros componentes que ya están bien muertos).

3) Hasta que punto este enfoque es independiente de FireBird (tenemos un posible cliente que si no es con SQL server no quiere, el responsable de IT trabajaba antes en MS en los USA y los añora mucho?

Yo me quedé con SQL Server 7, pero en su época me cambié al Firebird (casi igual de potente, pero de programación mucho más simple y sobretodo más ligero para ponerlo con nuestro programa y para administrar).

Así que nunca programo aplicaciones multi-base de datos. Pero amigos míos sí que lo han hecho (trabajando con dbExpress + ClientDatasets + Firebird + SQL Server). Y funciona perfectamente. Para la inmensa mayoría del código, solo cambias la conexión dbExpress para que apunte a Firebird o a SQL Server, y la aplicación ya funciona correctamente, sin ningún cambio en el código.

Claro que no todo es perfecto, y a veces te vas a encontrar con que una consulta tiene sintaxis diferentes en Firebird o en SQL Server, y por eso tienes que programar la aplicación para que en un caso lance una o la otra. Aunque como cada vez más los desarrolladores de Firebird y de SQL Server se comprometen con respetar los estándares SQL, cada vez es más fácil escribir consultas complejas que funcionan igual de bien en Firebird y en SQL Server.

4) Como es la estructura concreta de la aplicacion: En cada form (ficha, dbgrid, o lo que sea) supongo que teneis un ClientDataSet, pero ¿Cada ClientDataSet contra que conecta?

Yo utilizo un TSQLQuery o un TpFibDataset (depende de la aplicación uso dbExpress o FibPlus, ya que puedes usar cualquier componente que te devuelva un TDataset), esto se conecta a un TDatasetProvider, el cual es el enlace con el TClientDataset con el que trabajas de verdad en la aplicación y al que están conectados todos los controles datacontrols.

En su dia miramos los dbExpress pero no nos gustaron por un tema que no se si ya estara resuelto: Si haces un select * from tabla con FreeIB, y en tu grid se muestran 20 lineas, solo se "trae" del servidor FireBird las primeras 20 lineas, es decir, que las FreeIB se ocupan de pedirle al serivodr solo los record que relamente se muestran, mientras que los dbExpress se traen todos los record al ejecutarse.

En realidad dbExpress no se ocupa de eso, es el ClientDataset el que lo hace.

DbExpress solo hace cursores de solo avance y solo lectura. Es decir solo puede leer registros de uno en uno y siempre para adelante, y no puede modificarlos.

El ClientDataset es el que te permite mover por los registros hacia delante o hacia atrás, y modificarlos. De la misma forma el ClientDataset es el que escoge leer todos los registros (que es lo que hace normalmente), o leerlos por partes. Para esto último solo tienes que poner la cantidad de registros que se lean cada vez, en la propiedad PacketRecords (por defecto a -1 = todos). Pero eso funciona perfectamente (aunque yo nunca lo utilizo) pero tiene un problema, y es que mantiene abierto un cursor en el servidor Firebird (igual que hace FreeIB y todos los componentes con lectura incremental), cosa que va en contra de la filosofía de dbExpress + ClientDatasets (minitransacciones que pasan toda la información al cliente para que lo gestiones desde allí). Marteens estudia varias soluciones a partir de la página 688 en La Cara Oculta de Delhi 6 (supongo que lo tienes, en caso contrario descargalo, es un libro básico y Marteens ya lo ha liberado al público).

Por eso funciona tan bien dbExpress, porqué es un driver de acceso absolutamente mínimo a la base de datos, deja que de todo el resto se ocupen componentes de tu aplicación, como el ClientDataset.

Si los dbExpress no tienen ocion de traerse solos los records conforme se utilizan, tendriamos que plantearnos controlar eso desde programa, porque ahora usamos con mucha alegria select que se traen miles de record complejos SIN agobiar excesivamente al servidor ni quedarnos sin meoria (bueno, si pides un listado de esos datos, te quedas sin memoria, eso si).

Yo utilizo normalmente consultas que se traen miles de registros, y te puedo asegurar que mis programas ni se despeinan (eso sí, no hago select *, sino que solo consulto los campos que necesito). Y desde luego, para no agobiar al Servidor, no hay nada como trabajar de esta forma, sin mantener nunca cursores ni transacciones abiertas.

Saludos.

[Sergio]

Gracias por la contestacion, Marc.

Lo de los usuarios de FireBird, aqui hacemos igual, porque controlar los usuarios si la base de datos no esta bajo "tu poder", como en nuestor caso que pueden haber 200 o 300 bases de datos por empresas usando nuestras aplicaciones, como que da cosa, sobre todo cuando empezamos que era la epoca pre-FireBird (Interbase 6).

Lo que creo que no calibré al preguntarte es que tu debes usar la version enterprise/architect, y aqui en principio solemos tirar por la profesional, con lo que creo -no lo he comprobado- que no trae esos componentes, asi que o nos costara mas dinero migrar a delphi "moderno", o usaremos IBObjects o UIB, las otras dos opciones que barajamos (UIB es perfecto para nosotros, pero ya veremos al cambiar unos por otros donde empieza a quejarse).

Ya te contare como acaba la eleccion de componentes!

[Marc]

Hola Sergio.

Lo que creo que no calibré al preguntarte es que tu debes usar la version enterprise/architect, y aqui en principio solemos tirar por la profesional, con lo que creo -no lo he comprobado- que no trae esos componentes, asi que o nos costara mas dinero migrar a delphi "moderno", o usaremos IBObjects o UIB, las otras dos opciones que barajamos (UIB es perfecto para nosotros, pero ya veremos al cambiar unos por otros donde empieza a quejarse).

Yo también utilizo versiones profesionales de Delphi (no nos podemos permitir las otras, son carísimas  ).

Es cierto que Embarcadero a partir de Delphi 2010 han añadido un driver dbExpress para Firebird solo para las Enterprise/Architect.

Pero eso no te impide utilizar cualquier otro driver dbExpress Firebird, open source o comercial, sobre Delphi Professional.

Open Source :

http://sites.google....te/dbxfirebird/  (lo he probado y todo parece funcionar bien)

Comercial (te pongo el que me parece mejor, pero hay más) :

http://www.devart.com/dbx/  (a partir de 99,95 dólares)

[Sergio]

Hola de nuevo Marc,

Estamos retomando este tema a ver si llegamos a ser "compatibles con D2007 y UniGUI", y nos surge unas pocas cuestiones respecto de esto del dbExpress y los ClientDataSet, a ver si puedes arrojarnos algo de luz:

1) Si vas a dar de alta una factura, es decir, la cabecera de factura, mas sus n lineas de factura, mas su asiento contable, mas su asiento de IVA, mas lo que sea que toque: Puedes agrupar todo esto en una transaccion "clasica" y que o todo se grabe o nada?

2) El ClientDataSet va bien para dbGrids o para fichas estandard, pero si quieres una consulta con parametros, con un ExecuteBlock, y demas cosas "avanzadas" ¿Como se hace con este esquema? Suponogo que depende del DataSet de donde partas, perome refiero a usando dbExpress (igual no se puede y usas otros sistemas alternativos para estas cosas).

Gracias de antemano.

[Wilson]

Aunque la pregunta es para Marc, te adelanto algo.

Si se pueden crear transacciones clásicas, en el lado servidor se pueden utilizar los manejadores de eventos del TDatsetProvider para iniciar la transacción explícitamente, monitorearla, y confirmarla o cancelarla.

También desde los TClientDatasets puedes en cualquier momento cambiar el contenido de la consulta (incluidos sus parámetros) utilizando la propiedad CommandText.

Cuando quieras te puedo hacer un pequeño ejemplo de lo anterior.

Saludos

[Sergio]

Gracias Wilson, tus aclaraciones son justo lo que buscaba, no es necesario que te curres -trabajes, no se si fuera de españa se usa mucho currar- un ejemplo, me queda claro que todo lo que quiere es posible y facil, los detalles los anoto para cuando me mete en harina.

Gracias de nuevo!

[Marc]

Hola Sergio.

Hola de nuevo Marc,

Estamos retomando este tema a ver si llegamos a ser "compatibles con D2007 y UniGUI", y nos surge unas pocas cuestiones respecto de esto del dbExpress y los ClientDataSet, a ver si puedes arrojarnos algo de luz:

1) Si vas a dar de alta una factura, es decir, la cabecera de factura, mas sus n lineas de factura, mas su asiento contable, mas su asiento de IVA, mas lo que sea que toque: Puedes agrupar todo esto en una transaccion "clasica" y que o todo se grabe o nada?

Yo pensaba que si abrías manualmente una transacción, el ApplyUpdatase del ClientDataset la detectaba y se ejecutaba dentro de esa transacción (con lo que puedes agrupar varias grabaciones), y tengo escrito todo el código así.

Pero haciendo unas pruebas, el otro día, me parece que esto no acaba de funcionar exactamente así. Por lo que no he acabado de investigarlo, pero seguro que hay una forma para indicarle al ClientDataset que haga sus grabaciones sobre una transacción explícita.

2) El ClientDataSet va bien para dbGrids o para fichas estandard, pero si quieres una consulta con parametros, con un ExecuteBlock, y demas cosas "avanzadas" ¿Como se hace con este esquema? Suponogo que depende del DataSet de donde partas, perome refiero a usando dbExpress (igual no se puede y usas otros sistemas alternativos para estas cosas).

Gracias de antemano.

No hay problema, el ClientDataset puede utilizar cualquier tipo de consultas, con parámetros, basada en un ExecuteBlock, etc. ....

Cualquier consulta que te devuelva un conjunto de datos, se puede usar para alimentar un ClientDataset. NOTA: El problema si acaso será en como aplicar de vuelta los cambios a la base de datos, pero siempre hay soluciones.

Saludos.

[Sergio]

Yo pensaba que si abrías manualmente una transacción, el ApplyUpdatase del ClientDataset la detectaba y se ejecutaba dentro de esa transacción (con lo que puedes agrupar varias grabaciones), y tengo escrito todo el código así.

Pero haciendo unas pruebas, el otro día, me parece que esto no acaba de funcionar exactamente así. Por lo que no he acabado de investigarlo, pero seguro que hay una forma para indicarle al ClientDataset que haga sus grabaciones sobre una transacción explícita.

Gracias por tu respuesta Marc, yo entendi, segun tu explicacion, que esas microtransacciones eran automaticas y por eso di por hecho que varias cambios irian en varias transacciones de forma natural.

El amigo Wilson explica mas arriba que el DataSetProvider tiene una transaccion para estos usos, mas no te puedo decir, solo que siento que hayas descubirto que las transacciones te son infeles, pero mejor asi que se de cuenta tu cliente y te saque los colores!

Nuestras aplicaciones cantarian inmediatamente si algo asi ocurriese, es frecuente procesos largos creando records en la misma tabla desde varios pc, y ademas de tenerlo muy pensado para sacarle jugo a las transacciones, nos toca en ocasiones usar semaforos -hechos "a mano"- ademas de los contadores de FireBird, claro, por eso me interesa mucho como acorazar estos puntos grises del programa. Aun así, hay choques, y nos toca reintentar 10 veces a ver si en una cuela (es raro pero ocurre de vez en cuando), y si no se puede, que eso si que es raro rarisimo, pues mensajito tonto con boton de reintentar, asi mientras lo lee se pasa el problema!

[Wilson]

El amigo Wilson explica mas arriba que el DataSetProvider tiene una transaccion para estos usos, mas no te puedo decir, solo que siento que hayas descubirto que las transacciones te son infeles, pero mejor asi que se de cuenta tu cliente y te saque los colores!

No es justamente que el TDatasetProvider tenga transacciones, sinó la posibilidad de manejar las transacciones de las  que dispone dbExpress.

Lo ilustro en el siguiente ejemplo, en donde  en un módulo de nombre TDMSolicitudes hay un TDataSetProvider de nombre Solicitudes, en el primer bloque noten que he asignado en los eventos OnBeforeUpdateRecord y OnAfterUpdateRecord procedimientos (de la vida real)  que actualizan otras tablas y que eventualmente podrían fallar, por eso los controlo con la transsacción en los eventos OnBeforeApplyUpdates, OnAfterApplyUpdates y en OnUptadeError.  Esto es en Delphi 2010, para Delphi 2007 creo que es ligeramente diferente, pero el concepto es el mismo.

delphi

private
    FTransaccion: TDbXTransaction;
    
    //....
 
// Procedimientos suceptibles de fallas
 
procedure TDMSolicitudes.SolicitudesBeforeUpdateRecord
  (Sender: TObject; SourceDS: TDataSet; DeltaDS: TCustomClientDataSet;
  UpdateKind: TUpdateKind; var Applied: Boolean);
begin
  if UpdateKind = ukInsert then
 
    if SourceDS = qSolicitudes then
      DeltaDS.FieldByName('NUMERO').NewValue := GetNumeroSoli
    else
    DeltaDS.FieldByName('ID_DETALLE').NewValue := GetIdn;
end;
 
 
procedure TDMSolicitudes.SolicitudesAfterUpdateRecord
  (Sender: TObject; SourceDS: TDataSet; DeltaDS: TCustomClientDataSet;
  UpdateKind: TUpdateKind);
var
  S, T, ts: string;
begin
  if SourceDS = qSolicitudes then
  begin
    S := 'ID_SOLICITUD';
    T := 'SOLICITUDES';
    ts := 'SOLICITUDES';
    Controlar(T, ts, S, DeltaDS, UpdateKind, ConSol);
  end;
  if SourceDS = qDetSolicitud then
  begin
    S := 'ID_DETALLE';
    T := 'DETALLES SOLICITUDES';
    ts := 'DETALLES_SOLICITUDES';
    Controlar(T, ts, S, DeltaDS, UpdateKind, ConSol);
  end;
end;
    
    //manejo de la transacción
 
procedure TDMSolicitudes.SolicitudesBeforeApplyUpdates
  (Sender: TObject; var OwnerData: OleVariant);
begin
   FTransaccion := Conexion.BeginTransaction(TDBXIsolations.ReadCommitted);
end;
 
procedure TDMSolicitudes.SolicitudesAfterApplyUpdates
  (Sender: TObject; var OwnerData: OleVariant);
begin
  if Conexion.InTransaction then
    Conexion.CommitFreeAndNil(FTransaccion);
end;
 
procedure TDMSolicitudes.SolicitudesUpdateError(Sender: TObject;
  DataSet: TCustomClientDataSet; E: EUpdateError; UpdateKind: TUpdateKind;
  var Response: TResolverResponse);
begin
  if Conexion.InTransaction then
    Conexion.RollbackFreeAndNil(FTransaccion);
end;

PD: Todos  los anteriores eventos se disparan al hacer un ApplyUpdates sobre el TClientDataset asignado al proveedor Solicitudes.

Por ejemplo,  la función GetNumeroSoli obtiene un número consecutivo de una tabla contadora, si por alguna razón fallara la actualización a pesar de haber obtenido el número, jamás se alterará el consecutivo. Ahora te preguntarás porque asigno dicho número allí y no en un trigger, la respuesta es porque lo necesito de vuelta para imprimir la solicitud, y cuando tenemos en el proveedor la propiedad poPropagateChanges en true, todos aquellos cambios realizados por el proveedor se propagan al TClientDataset, esto para ilustrar un poco acerca de  las muchas  posibilidades y potencia que tienen los TClientDatasets.

Saludos

[Marc]

Hola Wilson.

En tu código, ¿ como aseguras que las actualizaciones del ClientDataset en el ApplyUpdates se van a ejecutar sobre la transacción FTransaccion, que has abierto en el BeforeApplyUpdates ?.

En ClientDatasets + dbExpress, si hay una transacción abierta en el SQLConnection, las actualizaciones del ClientDataset se ejecutan sobre ella, ¿ verdad ?. Por eso si quieres englobar la actualación de varios ClientDatasets en una misma transacción, solo tienes que abrirla manualmente antes de aplicar los ApplyUpdates (aparte de que como la transacción la controlas mediante tu código, en esa misma transacción puedes englobar la ejecución directa de SQLQuerys, o lo que sea que puedas necesitar).

Pero el otro día hice algunas pruebas con las FibPlus (en Delphi 2010 me pasé a FibPlus) y la cosa no acabava de ir bien (aunque no recuerdo exactamente los problemas que encontré).

Saludos.

[Wilson]

Hola Wilson.

En tu código, ¿ como aseguras que las actualizaciones del ClientDataset en el ApplyUpdates se van a ejecutar sobre la transacción FTransaccion, que has abierto en el BeforeApplyUpdates ?.

Marc,  cuando un proveedor va a iniciar la resolución comprueba si hemos iniciado explícitamente una transacción en el componente de conexión asociado al Dataset que oficia como fuente de datos de éste, si la encuentra (que es nuestro caso) entonces la utiliza, en su defecto inicia una (la resolución arranca en OnUpdateData, justo despues de BeforeApplyUpdates).

En ClientDatasets + dbExpress, si hay una transacción abierta en el SQLConnection, las actualizaciones del ClientDataset se ejecutan sobre ella, ¿ verdad ?. Por eso si quieres englobar la actualación de varios ClientDatasets en una misma transacción, solo tienes que abrirla manualmente antes de aplicar los ApplyUpdates (aparte de que como la transacción la controlas mediante tu código, en esa misma transacción puedes englobar la ejecución directa de SQLQuerys, o lo que sea que puedas necesitar).

Abrir la transacción manualmente es justo lo que hago en el evento BeforeApplyUpdates del proveedor.

Aclaro que esta es solo una técnica de tantas posibles, que aplica para necesidades específicas. Como bien sabes DbExpress es  lo suficientemente versatil para cubrir cualquier tipo de sutuación, por ejemplo para actualizaciones complejas bien podría  utilizarse un procedimiento almacenado,  incluso  este podría ser llamado en el evento apropiado dentro  de la resolución del proveedor.

Saludos

[ematrix]

Interesante pregunta:

Hace unos 4 o 5 años vi un articulo sobre que capacidad de almacenamiento, tenia Firebird

y esto fue lo que encontre


Windows:
FAT12 has a 32MB file size limit
FAT16 has a 2GB file size limit (Windows NT 3 or newer)
FAT32 has a 2GB file size limit
FAT32 has a 4GB file size limit (Windows NT5 / 2000 and newer)
NTFS has a 4GB file size limit (Windows NT)
NTFS has a 16EiB file size limit (Windows NT5 / 2000 and newer)
Linux:
EXT2/EXT3 (with 4kB blocksize) has a 2TB file size limit
EXT2/EXT3 (with 8kB blocksize) has a 64TB file size limit
ReiserFS 3.6 has a 1EiB file size limit
XFS has a 8EiB file size limit
JFS (with 512b blocksize) has a 8EiB file size limit
JFS (with 4kB blocksize) has a 8EiB file size limit


esto lo tome de un articulo

http://www.intitec.c...os-Firebird.pdf

claro esta que esto ha cambiado los sistemas FAT desaparecieron

Saludos

[Sergio]

Interesante pregunta:

Hace unos 4 o 5 años vi un articulo sobre que capacidad de almacenamiento, tenia Firebird

y esto fue lo que encontre


Windows:
FAT12 has a 32MB file size limit
FAT16 has a 2GB file size limit (Windows NT 3 or newer)
FAT32 has a 2GB file size limit
FAT32 has a 4GB file size limit (Windows NT5 / 2000 and newer)
NTFS has a 4GB file size limit (Windows NT)
NTFS has a 16EiB file size limit (Windows NT5 / 2000 and newer)
Linux:
EXT2/EXT3 (with 4kB blocksize) has a 2TB file size limit
EXT2/EXT3 (with 8kB blocksize) has a 64TB file size limit
ReiserFS 3.6 has a 1EiB file size limit
XFS has a 8EiB file size limit
JFS (with 512b blocksize) has a 8EiB file size limit
JFS (with 4kB blocksize) has a 8EiB file size limit


esto lo tome de un articulo

http://www.intitec.c...os-Firebird.pdf

claro esta que esto ha cambiado los sistemas FAT desaparecieron

Saludos

Esos son los limites para ficheros, en general.

FireBird V2 amplio mucho el tamaño posible, ahora esos tamaños son del orden de 16TB.