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

[Debra Waybright]

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!

Deb

[David Hall 5]

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.

[Todd Van Valkenburg]

I am getting use to editing fexs created by IA and then not being able to open them up again in IA. I am hoping that becomes less common in this newer version. But perhaps not

[Todd Van Valkenburg]

Thanks David. Good info. I will add a couple of your thoughts to our test plan.

[Todd Van Valkenburg]

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.

Thanks!

Todd

[john cullen]

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)

[Toby Mills]

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:

TABLE FILE CAR

SUM

CAR.BODY.DEALER_COST

BY CAR.ORIGIN.COUNTRY

ON TABLE SET HTMLCSS ON

ON TABLE SET STYLE *

INCLUDE = IBFS:/EDA/EDASERVE/_EDAHOME/ETC/endeflt.sty,$

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

ENDSTYLE

END

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:

[Adapters]

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.

Thanks

Toby

[Todd Van Valkenburg]

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.

Todd

[Manoj Chaurasia]

Todd

You can create a change management package and use a search tool (ie notepad++) against the files stored in the change package.

[Todd Van Valkenburg]

Thank you. Regarding your WITHIN and BY statement can you give me an example of what has changed starting in 8205

[john cullen]

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

(FOC1867) OPERATOR MUST BE AT THE LOWEST LEVEL OF AGGREGATION:

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.

[Todd Van Valkenburg]

jnc - I now found some reports that have SUM CNT.DST WITHIN.

And I got the FOC1867 error message.

So, is there an equivalent or workaround that you found to handle this And I am not sure what you mean by If thats not at the bottom of the BY list, that now fails in 8207.

Thanks again.

Todd

[Charles Morris 2]

What I found is that if you get the msg about it having been edited outside of IA just go ahead and continue, make a small change in IA, e.g. change a column title, save it. The annoying msg would go away

[Debra Waybright]

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.

[Todd Van Valkenburg]

Thanks. That is what I started doing. It has becomes a two step solution rather than one. I was just hoping I guess that some other method was introduced to replace it So I will create a hold file using CNT.DST BY. Then create the report on this hold file joining in other tables.