is there are FAQ or document anywhere that lists the limitations for functions in WebFOCS? Things like max length of a define, max number of defines, max string length that can be stored and referenced with IBI.FIL statement...

We are getting some unknown errors when trying to generate our reports... there seems to be a 4K limit on strings in the IBI.FIL calls.

Also, when we get these errors, we can't view source without the file opening as hex in Ultra Edit...

All input is welcome...

Thanks

Wayne

thats the insidious problem with UltraEdit... makes me nuts as well... UE insinuates itself as your default 'view source' tool, without your having asked it to do so, and there seems to be no way to unwind that feature, short of de-installing UE.
Reading HEX dumps give me .. flashbacks.

Wayne and Susannah,

Ultra Edit can be removed as the default View Source Editor by modifying the following registry key;
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\View Source Editor\Editor Name

Replace Ultra Edit in this registry key with your favorite...

Good Luck,

Kevin

thanks for the editor hint... unfortunately, I need an admin to change this so who knows when it will get done

As for the other limitations, is there anywhere I can look for this stuff?

WA

Wayne,

Unfortunately, in my 10+ years of working with IBI software, I have never seen a consolidated list of limitations. They are presented in various pieces of documetation where relevant, but not all in one list. I think most developers find workarounds for the various limits they bump up against, but usually after discovering the limit.

Sorry I can't be more helpful on this.

kevin

Maybe we could start a list of limitations, but where would we store it?

Hi,

Limitations for field lengths are in the Describing Data With WebFOCUS Language manual. Alpha is limited to 4K, and slightly less in some cases. This is documented in the section on USAGE formats.

Hope this helps.

Regards,
Jenn

Does this same limitation apply to the !IBI.FIL stuff? I thought that a record could hold up to 32K... We can work with an alpha of 4K if we can put multiples in the IBI.FIL and print out several alpha vars in a single call...

The problem we are hitting is this:
DEFINE FILE CAE_AGENT_PRODUCER
COL1/A4096 = 'SOME TEXT';
COL2/A50 = 'OTHER TEXT';
END

TABLE FILE CAE_AGENT_PRODUCER
PRINT
COL1
COL2
WHERE PRODUCER_SSN EQ '999999999'
ON TABLE HOLD AS REPORT FORMAT ALPHA
END

-HTMLFORM BEGIN
< HTML >
< HEAD >
< / HEAD>
< BODY >
< TABLE >
< TR >
!IBI.FIL.REPORT;
< TR >
< /TABLE >
< /BODY >
< /HTML >
-HTMLFORM END

This works if we only try to print out COL1 or COL2, but if we run this as is, it blows up...

Any help would be great.

WA

I just found out that the limit, at least for Oracle, for SQL passthru is 32K. Not insurmountable but slightly annoying

KevinG...bless your heart!

Thanks to everyone for the input. We currently have a case open with WF support, so we will see how that goes.

Unfortunately, we are not doing the run of the mill reporting with WF. We are wanting to allow for sorting, breaking, filtering, and formatting on the fly. To the best of my knowledge, this is just not possible with a report built using Developer Studio.

If someone can prove otherwise, I would love to see it as we made a decent investment in time and resources to get this project going. I would hate to relegate WebFOCUS to a graphing tool where we write all the middle ware and front end code to generate reports.

Again, thanks to everyone for their input...

Wayne

Wayne,

By Dev Studio, are you referring to Report Painter? We are a large shop and have highly modularized and dynamically created code coming from WebFOCUS. Of course, we don't use Report Painter that much because of what it can and can't do. We use a LOT of Dialogue Manger code and dynamically branch aroud -INCLUDE statements based on the values of &vars. We use WebFOCUS to dynamically build SQL statements, including IN statements, JOINS, GROUP BYs, ORDER BYs, etc. We dynamically style our reports in WebFOCUS based on the type of Output selected by the user. Although FOCUS and WebFOCUS have some annoying limitations, we haven't found many that we can't be overcome by creative coding. Much of this advanced stuff will never make it to a GUI report generator like Report Painter, but please don't underestimate what WebFOCUS is capable of in the hands of an experienced WF developer. We let SQL do what it is best at, but for dynamically creating SQL and formatting the output, WebFOCUS is unbeatable.

On a side note, WebFOCUS MAINTAIN is probably the most underutilized, most powerful front end you could put on WebFOCUS Reporting short of a full blown Java development team.

I wish I could bring you in and show our application to you, but my current employer would not allow it. Maybe another user is in a position to do that for you.

Sorry to rant a bit, but please stay positive,

Kevin

KevinG,

Thanks for the insights... I don't consider that a rant, more of an overview of what you have been able to do with the tool... You have to understand, my frustration is partially due to the limited knowledge we gained during the WF training sessions. We benefitted much more from the on site mentoring with one of the IBI guys...

At this point, we have all but scrapped the idea of working in Report Painter and deal only with a text editor. In fact we are writing a code generator that allows for our own macros for formatting and working with FOCUS Code. Developer Studio is just the place we go to access the fex in the text editor.

When we purchased the product, we were told it could handle everything we wanted to do, but as we are finding out, it requires a lot of development on our end.

When we hit this current roadblock, we had already refactored our code about 4 times to make it work. At that time, we had about 80 lines of FOCUS and Dialog Manager code and 1300+ lines of HTML and javascript. This seems a little excessive to me. Perhaps we need more knowledge of FOCUS, but when we reference the manuals, the functions we find either don't work as planned or are not documented well.

Our SQL statements are quite static with the exception of optional parameters. So, the SQL isn't what we are limited by. We have a list of requirements for the reporting package that we are having to manually produce. Here is a short list:
1. Actively filter a report based on the current results... (i.e. if the report contains all 50 states and we want to filter results to just Texas and Arkansas, we select Texas and Arkansas from a list and the report filters without hitting the DB again. Then we can further filter the active report to certain counties, crops, insurance plans etc...)
2. Single Column click sorting of a report without requerying the DB.
3. Managed Sorting of a report so we can set and maintain a sort order for result sets and then change the overall sorting of the results without hitting the DB.
4. Breaking the report into sections dynamically to logically group the data. LIke the filtering, but we want to put all crops from texas in a section (break) and so on. We want this to be dynamic so the user can decide how to group the data. Again, no return trip to the DB.
5. User formatting of data (i.e. change font, title of report, colors, etc...)
6. Show and hide rows/columns dynamically so the user can customize their view of the report.
7. Link to other reports based on a selection from a popup menu and this list is dynamic based on user settings.

Sorry this is so long, but that is a short list of what we want to do. Also, understand that the team is a team of software engineers that are used to writing their own everything. Our previous application was totally inhouse so that is the way we think.
If a tool doesn't do what we want, we open up Java, C++, Delphi, or whatever language we are best at and we write our own.
I am not ready to scrap WF at this point, since I have to answer to my bosses about why we selected a product that isn't working for us. But my developers have all but scrapped the product in favor of writing their own middleware and front end code.
While we have been waiting on a resolution to our 4K limit case, they have already reproduced in Java, and DHTML what we were trying to do for the past 2 months in WF.
We just don't seem to be using WF for its intended purpose.

To be honest, I would love for someone to look at what we have done and say "You guys could do all of this by just ??????" I would even share what we have done if it meant someone could show us how to use FOCUS for what we want.

Some of the functionality we want can be done in an Active Report, but those are limited to 5000 rows and our users generate reports up to 25000 rows. Some can be done with the Dashboard, but we can't buy that due to the licensing. Some of what we want could be done with an Hoc query tool, but so far we haven't found a way (short of writing it ourselves) to do everything we want in a single report.

I apologize for the length of this post, but if you made it this far and can offer any insights into how we can use WF to meet our needs PLEASE DON'T HESITATE TO RESPOND.

Thanks

Wayne

Wayne,
first, your fex has no table data tags, which might well be why you're bombing, when you use FORMAT ALPHA and then try to do all the html tagging yourself in your HTMLFORM.
second, as to your rant, that's just what IBI Consulting is all about. Sales people are just sales people, not developers.
Your requirements for 'not returning to the db' are 'active html' requirements, which is a webfocus version 7.x feature. The whole point of the word Web in WebFocus , per se, is that its a zero-footprint product, using the web for instantaneous deployment. Your requirement of 'not hitting the db' means no more zero footprint, you're depending on your browser do do a huge amount of work with active html;
All of your tasks are blissfully simple , lifting the requirement of not re-hitting the db. Adding that requirement puts all the work on the browser capaabiities.
The ibi training is generic, by definition.
It has to be.
You benefit more quickly with a consultant, either from ibi or one of the squadron of consulting firms like Resilient that have developers who've done it all before... As all developers will tell you, there are many ways to approach a situation, with this unbelievably flexible language and architecture, so an experienced developer can cut thru the fog for you. WF functions, as in the Using Functions Manual, all work. they flat out work, and have, for 30 years. I know. I've used them all. and written my own. The doc services response above to your issue with "4k limits on !ibi.fil references" seems off point, as it relates to field lengths,and your question seems to be completely different. but it is unclear to us what your question actually is?
{It started as a complaint about Ultra Edit, which i share, and KevinG cleared up for us.]
1. run your report without holding it as a REPORT file, just let it dump to the screen.
Does that work?
2. filedef your REPORT file to some place on your server, and then hold your output
ON TABLE HOLD AS REPORT FORMAT HTMTABLE
not alpha
Open it with your browser.
Does that work?
3. now try using the html form simplified
-HTMLFORM BEGIN
!IBI.FIL.REPORT;
-HTMLFORM END
Does that work?
4. if you must use the HOLD FORMAT ALPHA
then you must remember to do all the tagging yourself, carefully. Make sure your A4096 blocks don't contain characters that will make a browser choke. We use the CTRAN function on all big text fields to take out problems before we trip over them. Then We usually define a variable

DEFINE FILE ..
TDTAG/A4='<TD>';
-* nb you might put some widths on this tag to get your huge chunk of text to wrap nicely
TDTAG1/A5='</TD'>'
...
END
TABLE FILE ..
PRINT TDTAG MYVAR1 TDTAG MYVAR2 TDTAG1
...
ON TABLE HOLD AS MYTAB FORMAT ALPHA

but the need to do so much work is rare, only really experienced developers who want to tackle some html shortcomings )like fixing headers )will do this much work; We all usually let Focus do all the work.
Where is your local users group? do you hang out with them? You'll find developers at other companies are very willing to share with you.

This message has been edited. Last edited by: susannah,

susannah,

I am not trying to sound hostile or in any way trying to rant. The little jab aobut training is a sore spot, but in the future I will refrain. And we had great success with Scott from IBI. He was a wonderful help and got us past our first several hurdles. In fact, it was working with Scott that gave us ideas on how to expand on what we wanted to do...

I was writing my last post in haste trying to get my thoughts down and get out the door to take my son fishing... Apologies if it sounded rash.

Just to clarify, the original point of this thread was to ask about a documented source of limitations. The UE statement was an aside about functionality in UE that happens when we hit one of those limits. The post has since morphed into a more specific discussion of the limitation we are currently working on...

As to your list of things to try. We have gone through those in the course of debugging the problem and #3 does not work. I wrote my example fex code from memory and neglected to include a column from the table. Here is an example from CAR that will produce the error:

-* File carstest.fex
DEFINE FILE CAR
COL1/A4096 = '< td>' | COUNTRY | 'fdjskflsdjafsa' | '< /td>';
COL2/A50 = '< td>' | MODEL | ' ds as' | '< /td>';
END

TABLE FILE CAR
PRINT
COL1
COL2
ON TABLE HOLD AS REPORT FORMAT ALPHA
END

-HTMLFORM BEGIN
< HTML>
< HEAD>
< /HEAD>
< BODY>
< TABLE>
< TR>
!IBI.FIL.REPORT;
< /TR>
< /TABLE>
< /BODY>
< /HTML>
-HTMLFORM END

The limit is that !IBI.FIL.REPORT will not print the record that had more than 4096 characters in it. This is the limitation we are currently working on with IBI Tech Support.

As to your last paragraph, we are trying to give the user total control over the display, so that includes changing the column header format (font, alignment, etc...) as well as hook into mouse events when columns are clicked. We hook click events inside the tabular data as well. So the menu and actions are context sensitive.

If there is a way to post the entirety of our fex, I will happily do it. I think there is confustion as to what/why we are doing some things. And I mis-spoke in my previous post, we can sort, filter and do a lot of what we want without reaching the limit. Our problem comes about when we try to add dynamic breaks to the report. If we can do this using Sections or grouping some how in webfocus, I would appreciate any examples.


As a quick aside, we've looked into sections and they don't appear to work like we want. That is not to say they don't work. They work exactly as they are documented. But here is what we want to do. (Pardon the terrible and way to simplistic example)

1. Initial Report returns:

Year State Country Make Model
1996 TX USA FORD EXPLORER
1997 TX USA FORD F150
1997 TX USA GMC SIERRA

2. User Breaks by Make and new report returns
FORD
Year State Country Model
1996 TX USA EXPLORER
1997 TX USA F150

GMC
Year State Country Model
1997 TX USA SIERRA

3. User breaks by Model
FORD
EXPLORER
Year State Country
1996 TX USA

FORD
F150
Year State Country
1997 TX USA

GMC
SIERRA
Year State Country
1997 TX USA

4. User can reset back to original by selected reset and gets
Year State Country Make Model
1996 TX USA FORD EXPLORER
1997 TX USA FORD F150
1997 TX USA GMC SIERRA

Inside each of these breaks, we want to be able to sort, filter and format inside of each sub-table.


Also, if someone would like to look at what we are doing, I would happily email the source...

Thanks for all the help...

Wayne

This message has been edited. Last edited by: Wayne Atchley,

Wayne,

The first thing that hits me from this wish list is the concern about the amount of data that you will be expecting the browser to handle as you say you don't want to hit the server again. If it is many records then you obviously have to consider the memory available on the end-user machines - but you knew that.
Another thing I think you should consider carefully is the browser of choice.
One of the things that you will notice about the active HTML documentation from IB is that there are different limitations on different browsers - for instance IE 5,000 records by 15 columns or FF 20,000 records by 15 columns.
This should immediately trigger concerns if you intend to use IE throughout as there are good reasons why IB suggest these limitations.

I hope the fish were biting!!

T

Thanks Tony... the fish were biting and we had a blast.

As for browser, we work for the gov't and in their wisdom they have selected IE as the only browser we can use. Specifically it's the USDA, and other agencies may have different options. But for now, we are stuck with IE. When I said we don't want to hit the DB it's to limit traffic to Oracle. We are using hold files on the server to cache the results. This has been working pretty well so far.

One of the only good things about gov't control of our environment is they make sure the machines that will access the system are standardized, so the development machines are in line with the end user machines for the most part. Our currrent system limitation is 25,000 rows and we have no problems with that.

We are also implementing paging for the result set - which is a pretty common way to handle large amounts of data.

I have a proof of concept demo in 2 weeks to show what we are able to do with our new system. We can still use WF to do every piece of what we want, we just can't seem to get all pieces to work together in the same report. If we remove the custom formatting, row/column rollover highlighting and a few of the other things we can make the core requirements of sort, filter, and break work.

I would very much like to use the product, so please don't mistake my frustration for animosity towards the product. WebFOCUS was selected because it was the best BI product we saw during our research. We are just having some growing pains and I am certain no one was able to do everything they wanted with the product i nthe first 2 months of use... That is why we keep hitting FOCAL point for answers and or hints...

Thanks again for all the replies...

Wayne

Any chance of using Excel Pivot Tables? Just a thought!

Wayne,

Don't worry if you think your post sounds a little pointed, I can assure you that is not how I (and most of us on the Forum?) take it. I have dig now and then (if you hadn't noticed ) and can assure you that, even after 20 odd years of using FOCUS, I still get frustrated at times.

On the subject of the apparent 4096 char width limit, have you tried using HTMTABLE output and CSS to style your reports? Someting like this -

SET BYDISPLAY = ON
SET PAGE-NUM = NOPAGE
SET HTMLCSS = ON

DEFINE FILE CAR
COL1/A4096 = COUNTRY | 'fdjskflsdjafsa' ;
COL2/A50 = MODEL | ' ds as' ;
END

TABLE FILE CAR
PRINT
COL1
COL2
ON TABLE HOLD AS TEMPHTML FORMAT HTMTABLE
ON TABLE SET STYLE *
 TYPE=DATA, COLUMN=COL2, CLASS=NumData, $
 TYPE=DATA, COLUMN=COL1, CLASS=FstBy, $
ENDSTYLE
END
-RUN

-HTMLFORM BEGIN
<html>
<head>
<title>Inline using CSS</title>
<style>
  .NumData {color:red; border:3; position:relative; left:50; width:200; text-align:right;}
  .FstBy {color:blue; border:0;}
</style>
</head>
<body>
!IBI.FIL.TEMPHTML;
</body>
</html>
-HTMLFORM END

Obviously there are not 4096 chars in COL1 in your example and only using your data will this be proved to be a viable alternative or not.

I've had a look at some traces from the Servlet and there seems to be a Java problem underlying the agent crash. With more time I could look at the Java traces, but time for me doesn't exist too much at present, apart from the fact I should imagine (hope?) IB are at last at that stage?

Good luck with your demo and keep plugging away, the Forum is there for problems like these

T

Wayne, not on the 4096 thing, but on the user-capability thing,
it sounds to me as though you're trying to give your end user the ability to do all the native stuff in MRE Report Assist.
It seems to me that you would have alot less ajita if you just set up a few reporting objects and turned 'em lose on MRE.
I've done that here with great success..i've got smiling users...and they don't have to bother me with every little wee thing they think up... [uh, wait, they still do that.]
Terry's suggestion of pivot tables goes to the same point. A nice little Report Assist experience in the hands of one of your POC audience members could work wonders ...

I will look into MRE, but I am not sure if we purchased that package...

As for the HTMTABLE we looked into that, but we are wanting to include some event tags and such, and my developers tried this but they had no luck... here is a sample of what one of the rows might contain...

DEFINE FILE DATAROWS
TABLEROW/A84 = '< tr unselectable="on" onmouseout="rowmouseout[);" onmouseover="rowmouseover[this);">';
REINSYRID/A48 = '< td id="REINS_YR_ID" unselectable="on">' | TRIM('L', PTOA(REINS_YR_ID, '(P11)', 'A11'), 11, ' ', 1, 'A4') | '< /td>';
PRODUCERNM/A90 = '< td id="PRODUCER_NM" unselectable="on">' | LCWORD(46, PRODUCER_NM, 'A46V') | '< /td>';
ROPAIRINGCD/A48 = '< td id="RO_PAIRING_CD" unselectable="on">' | RO_PAIRING_CD | '< /td>';
POLICYNBR/A54 = '< td id="POLICY_NBR" unselectable="on">' | TRIMV('L', PTOA(POLICY_NBR, '(P11)', 'A11'), 11, ' ', 1, 'A11V') | '< /td>';
CROPCD/A70 = '< td id="CROP_CD" unselectable="on">' | LCWORD(30, CROP_NM, 'A30V') | '< /td>';
REGIONALOFFICE/A68 = '< td id="REGIONAL_OFFICE" unselectable="on">' | LCWORD(20, REGIONAL_OFFICE, 'A20V') | '< /td>';
RCONM/A59 = '< td id="RCO_NM" unselectable="on">' | LCWORD(20, RCO_NM, 'A20V') | '< /td>';
FIPSCD/A70 = '< td id="FIPS_CD" unselectable="on">' | LCWORD(30, COUNTY_NM, 'A30V') | '< /td>';
STATECD/A56 = '< td id="STATE_CD" unselectable="on">' | LCWORD(15, STATE_NM, 'A15V') | '< /td>';
PRODUCERSSN/A54 = '< td id="PRODUCER_SSN" unselectable="on">' | PRODUCER_SSN | '< /td>';
PRODUCERPHONE/A60 = '< td id="PRODUCER_PHONE" unselectable="on">' | '(' | EDIT(PRODUCER_PHONE, '999$$$$$$$') | ')' | EDIT(PRODUCER_PHONE, '$$$999$$$$') | '-' | EDIT(PRODUCER_PHONE, '$$$$$$9999') | '< /td>';
PRODUCERCITY/A81 = '< td id="PRODUCER_CITY" unselectable="on">' | LCWORD(35, PRODUCER_CITY, 'A35V') | '< /td>';
PRODUCERSTATE/A54 = '< td id="PRODUCER_STATE" unselectable="on">' | PRODUCER_STATE | '< /td>< /tr>';
END

TABLE FILE DATAROWS
PRINT
TABLEROW
REINSYRID
PRODUCERNM
ROPAIRINGCD
POLICYNBR
CROPCD
REGIONALOFFICE
RCONM
FIPSCD
STATECD
PRODUCERSSN
PRODUCERPHONE
PRODUCERCITY
PRODUCERSTATE
ON TABLE HOLD AS REPORT FORMAT ALPHA
END

This is a watered down version, but this is a sample of what we are trying...

Wayne

Wayne,

I assume you have a master file description called DATAROWS and it includes the fields you are using in the DEFINE statement. The first Row of the DEFINE has a problem in that you are defining it as an A84, but the text contains 86 characters. When I change it to an A86, the error goes away for that line. I am unable to go further, as I would need to create a data file and MFD that contains the fields you are performing functions on in the define, but please check your formats and get accurate counts of the lengths of the strings you are trying to define.

Hope this helps,

Kevin

Hi Wayne,

I double-checked with product management and they recommend if you are hitting the current 4k boundary/limit and having problems, you should open a New Feature Request to increase to the boundary/limit.

Hope this helps.

Regards,
Jenn