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.
I have a report that needs to check for a valid list of users and then take their user codes and retreive data, for those users, from a second table. We are currently accomplishing this by reading the user table into a hold file and then writing a join to the activity data. But it is running extemely slow. In an attempt try and speed things up. I wanted to do a where in file ???. But no matter what format I put the hold file in it's always adding extra charaters to the SQL statement. Example. If the user code is jjohnson and I use a alpha format the in statement produces where in ('00005jjohnson'). An HTML format produces format produce
('jjjohnson<td>').
Is there a specific format I can use to eliminate the extra characters?This message has been edited. Last edited by: <Kathryn Henning>,
WHERE IN FILE will work a lot faster than joining to a WeBFOCUS HOLD file - a SQL to non-SQL join is not efficient.
The format for WHERE IN FILE should be ALPHA or BINARY. The "extra characters" are most likely due to the column being a variable length column. You can change the format of the column when holding the file, something like:
TABLE FILE USER_LIST
PRINT
USER_ID/A50
WHERE (validation)
ON TABLE HOLD AS HUSER_LIST FORMAT ALPHA
ON TABLE SET HOLDLIST PRINTONLY
HOLDLIST PRINTONLY is required because the column format is being changed 'on the fly' - two columns would be in the hold file without HOLDLIST PRINTONLY.
Meanwhile, can't you do this in one SQL statement? If the tables are of the same type and in the same database, you could do a join and put your user validation criteria in the same SQL statement...
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
like francis say, its the SET HOLDLIST PRINTONLY it looks to me like you're doing PRINT USERCODE BY USERID NOPRINT and that's how the 00005 is getting in there. so, again, the NOPRINT is nice on screen, but in the extract file, you want to force it to hold only the same stuff you would see on screen, so the ON TABLE SET HOLDLIST PRINTONLY would work just dandy, like francis says. and the USERID wouldn't show up in the extract
In Focus since 1979///7706m/5 ;wintel 2008/64;OAM security; Oracle db, ///MRE/BID
Posts: 3811 | Location: Manhattan | Registered: October 28, 2003