We've had this case open for a very long time,
case #30922518, which I think is accessible to anyone who wants to review it.

Opened it back in April, and we simply need this functionality...both drill down and olap to work in the same report.

We are considering offering a cash reward to anyone who can solve this for us. let us know how much it would be worth to you to do this work.

Thanks.

Ahh.. the magic word CASH

quote:

30922518

I'm not sure if we can look into the cases of other clients.

Can you give us some more info? or a link to that case?

Jason,

Cases are by site code, we can't see yours without it, WHICH, you don't want to give out.

Post your case...

I typed in Jason's case number, didn't get much, but I did get the previous thread he had opened on this. I read the whole thing and got the impression that what Jason was trying to do couldn't be done.

Have you looked at Active Reports?

BTW Jason, I've got cases open for over a year and a half. Talk about patience!

Jason

I was rereading your earlier post on this case.
I would suggest to shorten all the amper fields. There is a limit on the total length and those boundaries might be different in a normal report compared to an olap.
Try to make the ampers as short as possible and not only the names but merely the values.

thanks for looking into this folks.
I've gotten all of my variables down to single characters and all of the values down to two-characters.

We can have more drilldowns when we do that before it crashes...about half of what we really need to have to get it to be 'right'.

GinnyJakes: sorry to hear about your 18 month old cases. We were starting to think we were being ignored as we were small fish compared to most folks who run webfocus, I'm glad to hear we aren't alone.

I would like to hear any other ideas. Here is a link to a thread that describes the issue just as well as reading the case would.
https://forums.informationbuilders.com/eve/forums/a/tpc/...331/m/5711003742/p/1

thanks again.

Jason,

Have you ever used tinyurl.com? It's a great website that can turn a very long URL into a short one. You send the short URL to you pals via email and when they click on it, the web browser automatically goes to the long URL.

E.g. Using the Javascript link provided by tinyurl, it took this URL:

https://forums.informationbuilders.com/eve/forums?a=tpc&s=1651093421&f=7971057331&m=9991086062&r=7291080162#7291080162

and turned it into this URL:

http://tinyurl.com/2ucwv2

I'm not sure how it works, but they probably keep a database of the URL's that were "tinurled".

I wonder if you can use a similar idea: using WebFOCUS code to store the long URL in a DB table with a short URL ID and pass the URL ID in the drill-down link, that when clicked on, would run a piece of WebFOCUS code to get the long URL from the DB table...

Jason,

After looking at the other fourm thread and your notes, it sounds like the number of variables and not the length may be the problem.

Try the following. Create 5 variables that will be passed to the next fex. These 5 variables will hold the value of 2 variables each with a separator (I like `). The next fex will then break up these 5 variables into the 10 that are actually used.

Fernando

Pretty good idea Fernando, if the issue is NOT the length of the URL.

Shot in the dark here, but I think your problem might be doable.

First, construct a focexec that returns your drill to fex, as well as all the potential values in xml format.
Second, Change your olap fex to only have 1 item in your multi-drill <= cause you know that works and we need the framework set up for us.
Third, build some JS that will consume the focexec in step 1, and add all the remaining stuff that is missing. This js would be introduced to the code via the JSURL setting, and use an ajax call to retrieve the xml document.

If I see it correctly, all you should need to do is add an MDitems for each of the remaining drill downs.

MDitems[0]=new Object();
MDitems[0].text="One";
MDitems[0].url="/ibi_apps/WFServlet?IBIF_webapp=/ibi_apps&IBIC_server=EDASERVE&IBIWF_msgviewer=OFF&IBIAPP_app=ibinccen&IBIF_ex=aa_drillto&";
MDitems[0].target="_blank";  

The logic seems simple enough, and your counter would start at 1 instead of 0.

Then your js should cycle through all the Anchors that have an href starting with "javascript:MDitemClick", and change the content to incorporate all the params that are needed to be passed (again, via the First step).

The only really challenging thing - as I see it - you would have to traverse the table cells to retrieve any data values that need to be included into the final drill down url's. Challenging, but not impossible! If you use Firefox's Dom inspector you should be able to figure it out pretty quick.

If I wasn't knee deep in production issues at the moment, I would try this myself - looks like fun. But, I am knee deep, so I will not be able to give this the old college try for a couple of weeks.

Let me know what happens if you decide to give this a kick.

p.s. If you do this and it works, do I get the cash?

jason, what happens if your shorten your parm names to the shortest possible construct..say 3 chars max...; You say that cutting off a few lines of the last dmi allows the olap to work.
so how about shortening. you can do it.
In your sample fex on the linked post...
instead of a zillion IF..GOTO,
set up the following:

-SET &cmt_yrc1=IF &YEAR_COUNT GE 1 THEN ' ' ELSE '-*';
-SET &cmt_yrc2=IF &YEAR_COUNT GE 2 THEN ' ' ELSE '-*';
-SET &cmt_yrc3=IF &YEAR_COUNT GE 3 THEN ' ' ELSE '-*';
-SET &cmt_yrc2=IF &YEAR_COUNT GE 4 THEN ' ' ELSE '-*';

then your code in that fex becomes alot less bewildering:

SUM
RETAIL_COST/P11BM AS 'Sales,This Yr.'
&cmt_yrc1.EVAL RETAIL_COST/P11BM AS 'Sales,Prior Yr.'
&cmt_yrc2.EVAL RETAIL_COST/P11BM AS 'Sales Two,Yrs Prior'
&cmt_yrc3.EVAL RETAIL_COST/P11BM AS 'Sales Three,Yrs Prior'
&cmt_yrc4.EVAL RETAIL_COST/P11BM AS 'Sales Four,Yrs Prior'

DEALER_COST/P11BM AS 'Projected Sales,This Yr.'
&cmt_yrc1.EVAL DEALER_COST/P11BM AS 'Projected Sales,Prior Yr.'
&cmt_yrc2.EVAL DEALER_COST/P11BM AS 'Projected Sales,Two Yrs Ago'
&cmt_yrc3.EVAL DEALER_COST/P11BM AS 'Projected Sales,Three Yrs Ago'
&cmt_yrc4.EVAL DEALER_COST/P11BM AS 'Projected Sales,Four Yrs Ago'

LENGTH/P11BM AS 'Net Comm,This Yr.'
&cmt_yrc1.EVAL LENGTH/P11BM AS 'Net Comm,Prior Yr.' 
&cmt_yrc2.EVAL LENGTH/P11BM AS 'Net Comm,Two Yrs Prior' 
&cmt_yrc3.EVAL LENGTH/P11BM AS 'Net Comm,Three Yrs Prior' 
&cmt_yrc4.EVAL LENGTH/P11BM AS 'Net Comm,Four Yrs Prior'

it took me an hour and a half and I followed the only solution that made sense to me, susannah's shortening solution. It didn't fix the agent crash, but it made the code prettier. There's something to be said of how more productive a clean environment can be.

I tried changing the ampers to single chars and the values, well, there's no way as they are all part of the where clause. If I'm looking for information for salesperson #3452, then I can't simply abbreviate it. We've been down this path a few times, but I've concluded that since the fex crashes before we even pass a single variable that the issue must be related to a the sheer amount of javascript (or some other technology) created by these multiple drill-downs.

Plain and simple, we don't even know where to look to find the source of the "EDASERVE has crashed. Check your server log." Where is this mystical "server log" that has all of our answers? Something tells me that a software company as large as this must have some sort of way of logging and analyzing even if there's a generic message displayed.

We'll do whatever it takes. This issue, and this issue alone, is all that stands between this company and a dashboard. Until we get OLAP to work with many drill-downs we will never have the ability to do what they can do now with spreadsheets,the silly iseries query tool and a lot of elbow grease.

Jason,

I think an example of my solution may help. I noticed that you have the following:

TYPE=DATA,
DRILLMENUITEM='Show PL Info for this Cust Class',
FOCEXEC=app/wcqrgj18.fex( \
BEGIN_MONTH ='&BEGIN_MONTH' \
END_MONTH ='&END_MONTH' \
REP_GRP_CHRONO ='&REP_GRP_CHRONO' \
REP_GRP_LOCALE ='&REP_GRP_LOCALE' \
etc...

You would use this instead:

TYPE=DATA,
DRILLMENUITEM='Show PL Info for this Cust Class',
FOCEXEC=app/wcqrgj18.fex( \
X_B_E_MONTH ='&BEGIN_MONTH.EVAL~&END_MONTH.EVAL' \
X_C_L ='&REP_GRP_CHRONO.EVAL~&REP_GRP_LOCALE.EVAL' \
etc...

The fex that is called will have do this:

-SET &LENA = POSIT(&X_B_E_MONTH, &X_B_E_MONTH.LEN, '~', 1, 'I2');
-SET &BEGIN_MONTH=GETTOK(&X_B_E_MONTH, &X_B_E_MONTH.LEN, 1, '~', &LENA, 'A&LENA.EVAL');
-SET &LENB = &X_B_E_MONTH.LEN - &LENA - 1;
-SET &END_MONTH=GETTOK(&X_B_E_MONTH, &X_B_E_MONTH.LEN, 2, '~', &LENB, 'A&LENB.EVAL');

-SET &LENA = POSIT(&X_C_L, &X_C_L.LEN, '~', 1, 'I2');
-SET &REP_GRP_CHRONO=GETTOK(&X_C_L, &X_C_L.LEN, 1, '~', &LENA, 'A&LENA.EVAL');
-SET &LENB = &X_C_L.LEN - &LENA - 1;
-SET &REP_GRP_LOCALE=GETTOK(&X_C_L, &X_C_L.LEN, 2, '~', &LENB, 'A&LENB.EVAL');

etc.

The first one pulls the first item using ~ as separator. The second one pulls the second item, etc. LENA is the len of the first item and LENB the second item. I reused LENA and LENB, but you don't have to. You can use shorter names for variables of course.

Hope that this helps.

Fernando

I don't know if things have changed for 7.6, but in 5.3, the log is here: C:\ibi\srv53\wfs\edaprint.log

I don't know how much the log will help you, since IBI hasn't been able to solve the problem yet.

The log is in the same place on all the releases discussed in these forums, i.e. drive:\ibi\srvnn\wfs\edaprint.log.

If you have admin privileges, you can see it from the Web Console. Now that is in different places depending on your release.

Jason, we hear your pain...I think we'ld all do the same thing...rebuild your fex, from scratch, bit by bit, until you see the first crash. an agent can crash on as silly a thing as a typo in a varname in a drilldown, the kind of "PEBKAC" (see the Shh post for xlation of that cute acronym) that most often requires sleep to find.

If this is a syntax issue, I'll go back to programming, where there's such a thing as a debugger that gives you a hint at an issue rather than just saying "your agent crashed, check your log" that really doesn't tell you anything.

Did IBI focus so much on this webfocus product that they figured nobody would want to debug their FOCUS code?

Jason, now that you're a FocalPoint guru, you shouldn't have to worry about petty things like debugging code

Hi Jason,

For your reference: case #30922518 is resolved with the 7.1.8 and 7.6.4 Reporting Server, and that it’s available for download via InfoResponse.

Hope this helps.

Cheers,

Kerry

quote:

30922518

Kerry, the solution appears to be:

quote:

Workaround: none

A search for the case provided this page:
Known Problem - Drilldown menuitem Unknown error occurred. Agent crashed

This is probably not the page that describes the solution!

Hi Francis, Jason, and all,

We are currently working on updating the case, so check it again in a day or so.

Cheers,

Kerry

well, I called yesterday IBI yesterday, referenced this case and left a 'request for call back' this email was senting in my box this morning...

"
Dear Jason:

As you should already be aware, this problem has been addressed with release
7.1.8 as well as the 7.6.4 reporting server. Since you are on the 7.6 track, the 7.6.4 version is available for download. Please let me know if you have any further questions or concerns related to this issue.

Regards,
*deleted*
Technical Support Supervisor
Customer Support Services
Information Builders
"

I guess I missed the boat somewhere about this update fixing the issue. If I would have known about this I would have installed it a month ago.

We will install the upgrade tomorrow, and hopefully that will get this case closed and move us into production!

quote:

30922518

Well, it is interesting that you or your company opened the case and were not informed that the patch specifically refers to your case until you contacted IBI...

-SET MY_REAL_THOUGHTS/A30 = REPLACE('FRANCIS'S COMMENT','interesting','FRUSTRATING');

The upgrade to 7.6.4 fixed the problem with multiple drill down and OLAP. It works!

You've got to make the announcement louder than this! It's good news! So, the cash reward goes to IBI?