| Subject | Re: [firebird-support] has the limit of 255 contexts been increased yet? |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2010-07-12T14:34:37Z |
Sam Watkins wrote:
The one Doug describes is the value of the table format (RDB$FORMATS)
which is carried in every record version as part of the record header.
You get that error the 255th time you try to modify a table by adding or
dropping a field, or changing its datatype. That error occurs on DDL
statements. The down-side of changing that value is that every record
would be one byte longer. The up-side is that a back-up/restore
cycle solves it.
Sam's problem occurs while a DML statement is being compiled. During
compilation, Firebird identifies all the data sources referenced.
They're called contexts, because they establish the "context" of
a field reference. If the query references a view made up of two
tables, that takes three contexts - one for the view, plus one for
each table. A view that joins two two-table views uses seven contexts,
one for the top-view, and three for the other two views.
I have forgotten the internal architecture of the compiler (old
age has its blessings) but my recollection is that from the context
there is a fan-out that means that most queries that have more than
255 contexts would run out of other types of memory. There are lots
of places internally that use a 16 bit integers for sizes of things.
I know that current developers are working on eliminating them.
> On 7/12/2010 5:59 AM, Sam Watkins wrote:That's two completely different 255 limits.
>> I am working on a complex firebird database at work. When I try to alter the
>> schema e.g. adding a join to a certain view, I later get this error:
>>
>> "Too many Contexts of Relation/Procedure/Views. Maximum allowed is 255"
>
> On Mon, Jul 12, 2010 at 08:21:57AM -0400, Doug Chamberlin wrote:
>> Firebird tracks revisions to database schema and can only retain some
>> 255 changes to any given table/view definition. If you backup and
>> restore the database the counter will reset to 0 so another 255 changes
>> can then be handled.
The one Doug describes is the value of the table format (RDB$FORMATS)
which is carried in every record version as part of the record header.
You get that error the 255th time you try to modify a table by adding or
dropping a field, or changing its datatype. That error occurs on DDL
statements. The down-side of changing that value is that every record
would be one byte longer. The up-side is that a back-up/restore
cycle solves it.
Sam's problem occurs while a DML statement is being compiled. During
compilation, Firebird identifies all the data sources referenced.
They're called contexts, because they establish the "context" of
a field reference. If the query references a view made up of two
tables, that takes three contexts - one for the view, plus one for
each table. A view that joins two two-table views uses seven contexts,
one for the top-view, and three for the other two views.
I have forgotten the internal architecture of the compiler (old
age has its blessings) but my recollection is that from the context
there is a fan-out that means that most queries that have more than
255 contexts would run out of other types of memory. There are lots
of places internally that use a 16 bit integers for sizes of things.
I know that current developers are working on eliminating them.
>
> I'm not dissing Firebird, I actually like it, but I think these limits at the
> 255th whatever are a nonsense anachronism.
>
> regards,
>
> Sam Watkins
>