Jump to content

We are starting to plan for an upgrade to 8207. Currently o...

Todd Van Valkenburg

Recommended Posts

Not sure this is code tightening, but thought Id share.

We are on 8.2.03 and are trying to go to 8.2.07 and have discovered an issue with reports created in IA that use hold files with define fields or aggregated fields. We have a case open and are hoping for a fix. What is happening is the syntax behind the scenes was changed so these reports created in IA prior to 8.2.06 break in 8.2.06 or higher. You can fix the code in the text editor after upgrading, but then you cant edit them in IA anymore.

Good Luck!


Link to comment
Share on other sites

We have done an upgrade from 8206 to 8207.27

The upgrade in place works very well. (Much better than in the past)

It is fairly painless in terms of the upgrade.

A few things to consider. If you have any extra things like fonts or java assist the upgrade will move these items to the backup folder. There is also a modification of the repository layout

I would recommend you work with your DBAs and make sure you have a backup of the Repository in case you need to recover. Post install there are some new roles that you need to review in the WF Admin Console. Also suggest you look at the HTML5 Charts to make sure the charts you enabled are still enabled.

Link to comment
Share on other sites

We are starting to plan for an upgrade to 8207. Currently on 8202. I have not gone through this process before but I read via this forum about code tightening that was required for 8207. If you have any specifics that I could do ahead of time while still on 8202 (search for this code and change it to this code), that would be great to know so that I can perform a code search/review sooner.



Link to comment
Share on other sites

I can name a few problems I ran into.

WITHIN and BY. They changed the behavior in 8205 that the BY has to be only on the highest level

JOIN FORMAT SQL_SCRIPT has a bug they fixed in 8207.27.01. it inserts a couple of lines with commas in the SQL, and the SQL generated in 8203 wont run in 8207.

HOLD FORMAT FOCUS with long lrecl hold files. They changed the max length per segment by a few bytes, so the hold file fieldname changes. like file.SEG02.fieldname, will now be file.SEG03.fieldname, resulting in the report made the the prior release doesnt run. When you open it in infoassist, it cant find the fieldname, and offers for you to select a replacement.

Those are three I can name. hold format Sql script was a showstopper for us, but its fixed now. The others you have to workaround.

I had a couple of issues with the upgrade and reportcaster that might be linux specific. The service wouldnt start, because of a mangled classpath with DSHOST, then it wouldnt stop, After fixing the classpath everywhere, it stops with traces on. (clearly they are working on something not quite finished in my opinion)

Link to comment
Share on other sites

Hi Todd

I hit an odd one that the product division is aware of, but they say it wont be fixed anytime soon.

The issue is using a full IBFS:/EDA path name to point to a stylesheet in a table request, but only if you have enabled the WebFOCUS Client REST adapter.

Heres the issue in code:








-** INCLUDE =_EDAHOME/ETC/endeflt.sty,$



The error youll see tells you this:


image.png86287 19.9 KB


Of course the .sty sheet does exist - its a default thing WebFOCUS examples might point to.

The workaround is pretty easy - jus dont use the IBFS:/EDA/EDASERVE in the name. Go back to the older way where you just say appfolder/thestylesheet.sty.

You can see in my code above where Ive commented out the way to make it work.

Again, this oddball issue only occurs if youve enabled the WebFOCUS Client REST adapter. One way to check for sure to see if you have it enabled is to look at your ibisrv82wfsbinedaserve.cfg. The [Adapters] section will have this:


wfcr_access = y

The workaround isnt hard but its annoying depending on how many places you have to change. We only enabled the WF Client REST adapter in 8207 to try to mimic some old BIP look and feel via Designer. So - I cant tell you if its always been this way or not.

Also I have no idea why enabling a given adapter would matter in locating a file on the WFRS, but apparently it does.

Most of the other things were finding were coding errors in the first place. Things like an extra semi-colon, or incorrect case on IBFS path names (as our old 8105m database was not case sensitive and the new one is). We also found some SET commands that should have been -SETs and were just never flagged as being in error to start with.

Some of our basic BIPs needed to be rebuilt. Wed end up with an extra panel in the BIP. Nothing I can think of that you can fix ahead of time - it was easier for us to just recreate the BIP in 8207 if we needed to.

Let us know if you hit anything new. Several of us either already have done the upgrade, or are in the midst of it.



Link to comment
Share on other sites

Thank you Toby.

I just tried a few things related to your comment.

I checked the edaserv.cfg and we do not have the wfcr_access. I also tried changing the path e.g. (INCLUDE=IBFS:/FILE/IBI_HTML_DIR/javaassist/intl/EN/combine_templates/endeflt_fso.sty,$ )

using a text editor to a mixed case, and it gave me an error right away. So guessing that will not be an issue for us since 98% of the time we are using InfoAssist. The SET vs -SET may be an issue but it would be difficult to find fexs need fixing in our Oracle repository DB ahead of time.


Link to comment
Share on other sites

You know it when you see it. Here is one example.


Youll get a different error message with prefix operators.

they changed the doc to say

The WITHIN phrase is very useful when using prefixes. The WITHIN phrase is not supported

with the MDN., MDE., DST., CNT.DST., AVE.DST., or SUM.DST. prefix operators in an

aggregation display command, such as SUM. The WITHIN phrase is supported with the

DST. operator with the PRINT display command.

I would suggest you search for all your procedures that use WITHIN and check them.

Our developers used SUBFOOT WITHIN. Pretty much all broken in 8207.

They also used CNT.DST WITHIN . If thats not at the bottom of the BY list, that now fails in 8207.

Link to comment
Share on other sites

  • 2 months later...

On the SUM CNT.DST WITHIN issue, I found this in my notes:

Per The Walters, the CNT.DST WITHIN simply adds the CNT.DST values of the first column. It can cause an unexpected result that is why they forced an error if you try to use it in the new version. They are trying to protect us from ourselves.

You probably have to use HOLD files to get the amounts you need.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...