As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
Apparently the number of OR's for TABLE requests does not have a (documented) limit. The total lengths of several TABLE-request expressions do have a limit (of 64kB) though, see: http://infocenter.informationb.../source/topic313.htm
With that in mind, any limit in the number of OR's or IN-list items is most probably decided by external factors; primarily the database you are querying and secondary the database adapter you're using (check the relevant adapter documentation for specifics).
As people stated already, for certain RDBMS's there are known limitations in the number of items in IN-lists. For the record, OR's usually get translated to IN-lists when converted to SQL, but that depends on the adapter.
One alternative when you're querying an RDBMS is to create a temporary table on the RDBMS with your lookup-items and perform a JOIN or WHERE IN (subselect) at the database side[1]. There are HOLD FORMAT's for that.
Ad 1. The limit on number of IN-list items is usually only applied to hard-coded lists within the query-string, but not for result sets from subselects and the like.
Finally, if you want to know if there is a limit to the number of OR's at your end, that's fairly easy to test!
TABLE FILE FOO
PRINT BAR
WHERE BAR EQ 1
-REPEAT :OROROR FOR &O FROM 2 TO 5000;
OR &O
-:OROROR
;
END
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
I discovered what I think is a weakness of the WebFOCUS SQL adapter. I have a Tree control from which a user can select up to 1200 values. I hand-crafted a beautiful piece of code to create a WHERE statement in which I separate the first 1000 selected values from the rest. When run in SQL, this works well. When run in WebFOCUS, the SQL adapter undoes the OR and creates only one set of values, which causes a SQL error as there are over 1000 values. It is my opinion that the SQL adapter is doing the opposite of what it should be doing. The SQL adapter should automatically separate the values into batches of 1000 values.
WHERE column IN ('val1', 'val2', ...) OR column IN ('val1001', 'val1002', ...)
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
WHERE column IN ('val1', 'val2', ...) OR column IN ('val1001', 'val1002', ...)
Seriously, that works? How reliable is this approach? It defies reason that RDBMSes that refuse to accept SQL statements with IN-lists with more than 1000 items would accept multiple IN-lists that still total more than 1000 items...
A good query optimizer would probably combine such IN-lists into one and could thus figure out what you're trying to do here - and refuse.
Then again, those arbitrary limitations on the size of IN-lists defy reason as well, so it's probably a matter of picking the lesser evil.
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
Adding this SET statement to your query will increase the number of values permitted in an IN FILE clause when used with SQL Server. I don't know if it has any effect with Oracle or other relational DBMS's.
ON TABLE SET NATVFLG 256
WebFOCUS 7.7.05
Posts: 1213 | Location: Seattle, Washington - USA | Registered: October 22, 2007