compiled engine limits [CORE1125] #1546
Comments
|
Commented by: @dyemanov 1) It's an artificial hardcoded limit intended to avoid process stack overflows caused by very long IN lists. It's documented, AFAIK. While it's possible to relax this limit a bit, we consider such programming patterns wrong. You can change this limit in the source code and recompile the server, if you wish. 2) I don't recall such a limit. It could be caused by other limitations or be something not known yet. Could you please provide a test case? 3) It cannot be increased easily, as it requires both an API change and a network protocol change. To be done either in v3.0 or later. |
|
Commented by: Sean Leyne (seanleyne) Rather than opening a tracker case, this should have first been discussed in the support or developer lists. Most of these issues have already been opened as cases. |
Modified by: Sean Leyne (seanleyne)status: Open [ 1 ] => Resolved [ 5 ] resolution: Won't Fix [ 2 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pcisarWorkflow: jira [ 11591 ] => Firebird [ 15302 ] |
Submitted by: David Kozik (d_kozik)
Hi,
we have found several limitations of Firebird while developing our (simple OLAP) application:
1) number of values in IN operator (1499)
2) number of parameters in parametric SQL where question-marks are used instead of parameters (4095)
3) SQL statement length (65535 characters)
Are you planning increasing of these limits in short-term developing plan?
Is it possible to change some of these limits by changing constant(s) and rebuilding sources?
Best regards,
D.Kozik
The text was updated successfully, but these errors were encountered: