At 03:51 AM 30/08/2005 +0000, you wrote:

>I have 117 GB in free space in the array. The documents are bigs but
>not that much. I only use 20 GB every 5 months.
>
>These is the reason i am fustrated.
>
>The last time i ask here for these problem Ann H. respond the following :
>
>"
> > Internal gds Software Consistency Check (Cannot Find Free Space (255)).
> >
> > what these error mean?
> >
>
>Yup. You've run into a problem with the size of tables. We've got a
>fix in V2, which is teetering on the edge of an alpha test. For now,
>the best alternative that I know of is to split your table in two.
>
>Regards,
>
>
>Ann
>"

Aaah - OK. I take it that you have all of this database in one huge
table. Yes, the Fb 2 changes should help increase the capacity of a table
beyond the ~2 billion record limit that prevails now.

>These is the reason i create other database to access new documents,
>but i continue with the problem.

Why don't you describe the archiving scheme which is behind this problem
system? If the table size limit is the source of your problem, why create
another database?

>My clients is very angry with me,
>becuase these big documents are very important for them to have acces
>in other branches.
>
>any help is welcome, even paying support, i need to resolve these
>problem fast.

The Firebird 2 release isn't imminent, for "fast". I'm not even certain
the new row-enumerating structure has found its way into an alpha yet -
Dmitry Y, are you watching?

So, if the row enumeration limit is your problem, then breaking up the
table seems to be your "Hobson's choice". A normalized archiving scheme
comes to mind as both the short and the long term solution.

./heLen