As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
I am working on a report for my client in which I came across a scenario where I get a column D_XXX_DS from oracle ref cursor, whereas in fex file I have used D_XX only but still it gives me the value what is expected by column D_XXX_DS.
There are 15 different columns returned from the cursor but column D_XXX_DS is the only column from the cursor starting with D.
What I would like to know is why this is happening in EDASERVE?
Are there any settings in webfocus for the same?
Thanks in Advance.This message has been edited. Last edited by: Kerry,
When making reference to a field, WebFOCUS will try to match the field name in your code (even if it's shorter) to an actual field in your data source and if it finds a match, it'll use that one.
So it makes perfect sense that WebFOCUS will recognize D_XX (as used in your .fex) as matching D_XXX_DS partially and will decide to use the latter, provided of course that no other field name can possible match the same partial name in the data source (which you already confirmed anyway).
Are you guys serious? It's hard to believe you did not know about NOTRUNC! It is one of my favourite and default settings in my reporting environment; very useful particularly when dealing with RDBMS tables (via masterfiles).
I used to like that WebFOCUS feature that allows accessing fields by using a truncated or short name. It was all good until the day when new fields were added to a database table and after refreshing the master file some reports that depended on it stopped working. The reason? those newly added fields had a similar prefix and the "truncated" name used in the .fex no longer matched a unique field but many of them By using NOTRUNC I am forcing myself to always use a complete field name instead of a truncated one; you may not do it on purpose but as the tool is very forgiving you may have code that runs fine without knowing that you have a potential bug.
Anyway, I'm glad something new was brought to the table. Well, not so new ... I use it in my WF 5.3.4 environment
Would you mind posting the code snippet where your query occurs as well as the content of your masterfile? One of us could spot something else such as perhaps the existence of a virtual field (DEFINE) or a short-named ALIAS for the actual database filed.
Neftali, I assume you're relatively new to the WF game, so you've memorized more recent documentation than us old fogies. I wish the default was NOTRUNC because I don't enjoy reading code like:
TABLE FILE CAR
SUM
SA
BY
CO
BY
MO
END
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
My code suddenly stopped working because CALENDAR_D now matches 2 different fields: CALENDAR_DATE and CALENDAR_DATE_YYMD. WF reports
(FOC003) THE FIELDNAME IS NOT RECOGNIZED: CALENDAR_D
Had I been more careful from the very beginning (even if it wasn't due to total laziness ) and used a complete field name I would not be facing that issue now. However by making WF less "forgiving":
SET FIELDNAME = NOTRUNC
TABLE FILE DATE_DIM
PRINT CALENDAR_D
WHERE RECORDLIMIT EQ 10
END
WebFOCUS would have thrown a very clear (FOC003) THE FIELDNAME IS NOT RECOGNIZED: CALENDAR_D since my first version of the code thus forcing me to use a complete name and avoiding a future bug.
Rahul, I don't understand why WF is still allowing a truncated name and matching it to your database field even with SET FIELDNAME=NOTRUNC. The behaviour I described above was seen in both WF 5.3.4 and 7.6.2. I don't see why it would be different in your 7.1.7 environment.
Now, that's an interesting piece of art ... and it works!
It makes me remember the old dBASE III days -I hope I'm not the only one here who remembers that - where every command could be written just by specifying its first 4 characters (REPL instead of REPLACE, for instance) which was fine for a "live" interaction to the database via prompt but that was taken too far by some people who coded their programs following the same 4-character approach creating a very ugly and difficult to understand (and debug) code.This message has been edited. Last edited by: njsden,
I remember that in FoxPRO, but the guys from Perrysburg were from Ashton Tate weren't they. And the original version of FoxPRO did look a lot like.. Wait, they didn't!
Now, that's an interesting piece of art ... and it works!
Now add "SET FIELDNAME = NOTRUNC" in fron of that and see what happens. Just as a POC and to prevent such things as "Had I been more careful from the very beginning and used a complete field name I would not be facing that issue now."
Posts: 3132 | Location: Tennessee, Nashville area | Registered: February 23, 2005
It's been a year since this was discussed and I haven't done it yet, but I will definitely put this setting in my default include. Doug, thanks for reminding me
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server