Hi everyone,

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.

Any thoughts?

Thanks in advance,
Brian

This 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.

GL

Thanks for your reply Martin.

I had tried debugging, nothing came up.
I just tried to save the file under a different name (same code) and scheduled that one. It worked perfectly.

This worries me as we have many deliveries under ReportCaster and I never thought it would "ignore" revisions and send out previous versions.

So strange...

Hi Yazster,

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?

Hi SWES,

Thanks for your reply.

I'm running from MRE.

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

quote:

My Content

), 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.

-Emily

Thanks Emily! Much appreciated.

I will take a look at your case and try to download the patch.

Installed the patch and all is working well now.

Thanks for all the assistance

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.

We had the same issue - patch installed, now working correctly