Commented by: GR (gr)

I think, it have to be configurable with 1000 by default.

Commented by: Philip Williams (unordained)

This would be fix the "too many contexts" (335544800) error, where the current limit of 255 contexts affects all versions of FB, not just 2.5 and up.

This limit is a nuisance when writing complex queries / views, especially in situations where you need a view's ability to be optimized on the fly, and replacing it with a stored procedure that "breaks up the work" would be less efficient at runtime, or you would need several depending on how you're intending to use it.

When you've been incrementally adding complexity to views and you hit this limit, there's not an associated rise in CPU or RAM usage that indicates this is a "good" limit. The queries perform just fine, up until they don't work anymore.

Is there any chance of getting traction on this? Can a 'fix version' be assigned, at least?

Commented by: @dyemanov

Philip, this is a completely different issue. It's about user context variables (RDB$GET_CONTEXT and RDB$SET_CONTEXT functions), not about internal relation contexts used in queries.

Commented by: Valdir Stiebe Junior (ogecrom)

Is there any workaround or open ticket about the "Too many Contexts of Relation/Procedure/Views. Maximum allowed is 255." for stored procedures?

Commented by: @dyemanov

The only one I've found is CORE809. And the only workaround is to break a complex SP into a few smaller ones.

Commented by: Valdir Stiebe Junior (ogecrom)

Thank you Dmitry.

Commented by: Philip Williams (unordained)

CORE2941 is a partial duplicate of this one. I find myself also needing an increased count of context variables (years later); MAX_CONTEXT_VARS seems to really only be used in one place, can we make it configurable? Also, internally, firebird::string appears to have a 16-bit size; why are context variables (which use MapString which are generic_map of firebird::string) limited to 255 char?

In my case, I have (currently, it's growing) 2008 bits of highly-volatile data I need to pass around between triggers and procedures, because 2008 individual index-scans at commit (!) are taking a while [scenario: like a spreadsheet, first dirty stuff, then on commit check to see what needs to be recalculated], and the triggers could inform on-commit procedures as to which work really needs to be performed and which doesn't. 2008 bits don't fit neatly into any one context variable; I can break them up into several, but then I also need to work out an encoding -- the easiest way to break them up leaves me near 255 per group, so I don't want to rely on byte-for-bit encoding; so then I need to look at something like BASE64 inside context variables to avoid issues with embedded \0 early-terminating my strings ... but that's not awfully fast, when i want to treat it as a large bit array for rapid bit-level get/set. Anyway. Current sizes are arbitrary and accidentally (you guys meant well!) inconvenient. Configurable limits (limits are still useful!) would be great. I'd rather not roll my own UDF and have to worry about implementing a thread-safe OS-agnostic stringmap, when there already is one that works so nicely.

Commented by: Norbert Saint Georges (arcantar)

I also modify the barrier of 255 to 1000 especially for nested views. The other RDBMS accept all views having more than 10 fields with more than 20 union that is currently blocking with FB.

Commented by: Tim Kelly (m00bh000)

I just got a :

Too many Contexts of Relation/Procedure/Views Maximum allowed is 256 with a complex query with many calculated expressions and lots of joins. Would modifying MAX_CONTEXT_VARS likely fix this problem pending a fix?

Commented by: @dyemanov

Tim, see my reply to Philip above.

Commented by: Norbert Saint Georges (arcantar)

Dmitry, ok and how to work around this limitation?

Commented by: @dyemanov

By simplifying the query and/or putting some of its SQL into selectable stored procedures.

Commented by: Norbert Saint Georges (arcantar)

this is not always possible, the limit is 255 per result / select
sub procedure \ function included in a select. Create a view with union repeating functions (fb3) is not possible

Commented by: @dyemanov

The limit is per request. Invoked procedures are separate requests and their bodies are parsed / optimized independently. So you *can* break a complex query into sub-procedures until you have 255 of them.

Commented by: Tim Kelly (m00bh000)

I can't break my query into sub-queries as the query is generated dynamically on the fly optimized dependent upon which fields a user is interested in .If I were to change to a static stored procedure model I would have to presume worst case scenario and select from tonnes of tables when the user may only actually need one field from one table. This would be far too expensive. The "Contexts of Relation/Procedure/Views Maximum" is a real showstopper for me.

Commented by: Tim Kelly (m00bh000)

Just hit this limitation once again - and running out of workarounds... I've deleted about as many columns as I can from my select. :(