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 firstname.lastname@example.org for further assistance. Reference the community FAQ to learn more about the community.
I have the strangest thing going on and I just can't seem to get it working.
I have a ReportCaster job that runs daily delivering a report (.FEX) by email. I made a change to the .FEX file yesterday (small where statement change) and published the change to production. When I ran the file in both DEV and Production, results were as expected.
Today when I received the report via email I noticed it was the old version without my changes. When I run the .fex file directly it works fine. When I look at the code my changes are there.
I tried the following: 1) Restarted Tomcat 2) Restarted the reporting server 3) Restarted ReportCaster 4) Cleared the cache via the admin console 5) Created a new ReportCaster schedule 6) Physically deleted the .fex and republished 7) Deleted the .fex, ran the schedule (got an error as expected), then republished and ran via ReportCaster, still old version. 8) Had other developers create new schedules under their own names, same thing
The only thing I haven't tried is rebooting the actual boxes but I can't do this during operating hours. I would hope this wouldn't be necessary though for such a small change.
Thanks in advance, BrianThis message has been edited. Last edited by: Yazster,
Report Caster is sometimes much more restrictive then the ReportingServer.
So it could be possible that you have an error somewhere in your code that make RC not running the new version of your code but running an old one.
Don't ask me how it can be possible, but I've already seens it.
Add debugging/trace in your fex to force RC to include them in its execution and -EXIT right after the step having your changes. Per example put -EXIT after the TABLE FILE ...END that has your change. Also add a -RUN after each TABLE FILE...END to insure that each possible warning/error is displayed where it occurs.
WF versions : Prod 8.2.04M gen 33, Dev 8.2.04M gen 33, OS : Windows, DB : MSSQL, Outputs : HTML, Excel, PDF In Focus since 2007
Posts: 2410 | Location: Montreal Area, Qc, CA | Registered: September 25, 2013
It looks like you've tried about everything indeed. My suggestions would be:
- put SET ERROROUT = ON on top of the fex and run the file in Dev Studio: this will make the procedure stop right away at the point in the script as it bumps into ANY error code, warning, etc if not... it just ends with the report output and you are sure that the report is not generating error messages. Assure yourself using this SET command that the script is working as it is supposed to.
- Just to make sure... have you double checked if there is no DUPLICATE fex around there somewhere from the old version? Can't tell if you're running from MRE or EDA, but make sure you look across app paths/domains for a file of the old version with the identical name? Maybe you accidently did a copy action without noticing yourself?
- put -SET &ECHO = ALL; in the fex to EXACTLY see what the procedure is doing in the ReportCaster logging, specifically on your modified WHERE statement, is it there yes or no?
WebFOCUS 8105m Windows 7, All Outputs
Member of the Benelux Usergroup
Posts: 198 | Location: Amsterdam | Registered: August 24, 2011
I tried the SET ERROROUT = ON as you suggested, no luck. I had the -SET ECHO=ALL; and although the ReportCaster log doesn't show me the output (only basic logging, not sure if there's a setting to show more), I viewed the log on the reporting server (workspace agent) and not surprisingly, my revised statement is not there.
The path of the .FEX file listed on the log is the right one. I've searched for another copy across the app paths/domains, nothing. My schedule is explicitly pointing to the .FEX in question, the log indicates this as well. If there was another version out there (let's say in
), it shouldn't interfere should it?
Seems obvious I guess that there's an older version out there being run by ReportCaster even though it's explicitly calling the one I want, but I don't see how this can happen. I would understand if it was located on the reporting server (EDA) and the order of the APP PATH would have an impact...
I'm going to try rebooting my Linux servers tonight.... who knows...
We just had this problem in 8.1.05. There is an issue with the caching on report caster. I put in a ticket and support gave us a patch that fixed it. Our case number was case 160901084 and they sent us RC-754_WF8015M_Gen68. It was an easy patch of just replacing a few library files.
Hope that helps.
WF 8.1.05 on Windows machines Backend: Informix, SQL and Oracle databases
Have your tried adding the WHENCE command to find where your FEX is getting pulled from. Sometimes there is an older copy hidden in another folder in the App Path. The results of WHENCE show in your message log.
WebFOCUS 7.7.05 (Someday 8) Windows 7, All Outputs In Focus since 1983.