Anybody out there using Business Views? I'm having a challenge in that changing the FIELDNAME property causes problems when creating parameters in reports.

When I go to the Variable Editor and select the Values for Field radio button in the Data Context area I can select the field based on the new name I created in the Business View but it does not return any values.

In the Object Inspector the Qualified Name of the field looks correct and the Alias references the original field name in the Synonym that the Business View is baed on.

I do have SET FOCTRANSFORM=ON set in the server profile.

Am I missing something or could this be a bug?

We are running v7.6.2

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

Hi Dan,

Do you have an updated status regarding this issue?

The suggestion for this issue would be similar to the other topic you have regarding DBA: the best channel for assistance would be your local SE's (you may want to contact your local branch) and/or education. The issue will involve a lot more details than providing simple information/directions.

Hope this helps.

Cheers,

Kerry

It is a bug ... contact tech support ... there is a workaround.

But for the rest of the viewers of this thread .. I am interested in if sites are using business views and how are they using them? Change names? Structure? Hide fields? etc.

"Art Greenhaus" method vs Business Views...
so far the ARt Greenhaus method wins, but it does not appear to work anymore in 764 (we have a case open to validate).
The principal reason we use the "AG" method is to hide KEY fields, they're ugly and useless to an enduser.
so..
USE
FILE1 AS FACTTABLE
FILE2 AS FACTTABLE
FILE3 AS FACTTABLE
END
JOIN KEY IN FACTTABLE TO KEY IN DIMTABLE AS J1
The AG method can hide the KEY easily
...
My read of the BV doc says i have to do this:
USE
FILE1 AS BV_FACTTABLE
FILE2 AS BV_FACTTABLE
FILE3 AS BV_FACTTABLE
END
JOIN KEY IN ... oops there's no KEY because its been taken out of the BV
My read of the BV doc says you can use a join IFF its in the original table's mfd, but i don't want to put a join in the original mfd.
Yes i could have a second master FACTABLE2 that contains JOINS, but then i have to maintain a second mfd everytime the original changes.
The hope of BV was that i would NOT have to change it when the original mfd changed. With AG, i had an alternate master and changed all the fieldnames in it.
The 2nd potential benefit of BV was the ability to rename a segment... which you can't do with just an alternate master
But as it is now, we have nothing.
AG doesn't work anymore and with BV we can't hide ugly keys .
Got any ideas?

A BV on top of an existing master can hide any field you have in the master.
Another way to hide a field is to use ACCESS=INTERNAL on the field in the original maaster. That will keep the field from showing up in any of the GUI trees. But it is still there and available to the syntax coders.

ah.
but the question was how to hide a field in 2 masters, the field that is the basis of a join.

so you're saying ACCESS=INTERNAL would be the way to accomplish the ArtGreenhaus technique on a pair of masters, and then still be able to use the KEY fields in a JOIN between two business views? Is that right?

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

I just tried adding ACCESS=INTERNAL to a master.
The RO wouldn't open, it bombed.
I searched for ACCESS=INTERNAL on the TEch Doc, and came up empty.
I searched for ACCESS=INTERNAL on the Advanced Search and the search crashed...i got "File cust_queryhit.idq. Unspecified error "

Could you point us to where this feature is documented?

according to the describing data manual, page 354, the possible values of the ACCESS= attribute are R,W,RW, and U only. Searching that manual, and the Developing RA and Creating.. manuals for ACCESS=INTERNAL comes up empty. Brian, can you please point us to the doc for your recommended technique?
thanks.

update: we can make BV's work beautifully by hiding the KEY fields that we might want to use to JOIN with
not by using access=internal (which doesn't seem to exist)
but by using the now-nicely-documented-and-formalized FocWizard trick
found for me by CSS (thanks Fred!)
This technique lets you perform a multitude of mischief, notably *not* showing certain fields
in the Reporting Object Field List, whether that RO is a BV or just an ordinary master.

It works. so, now that makes BV's wickedly cool and usable. I'll now try to catch up to Dan's original post and see what happens..

ACCESS_PROPERTY = INTERNAL

Sorry for quoting the wrong keyword ... and sorry for delay, your question back to me got lost in the fog!

no matter. JOINing 2 bv's doesn't work. which is fine. We built the combo mfd first, then a bv on top of that. worked like a charm, until we tried in RA to generate the list of values for a parm.
Same as Dan's original post.
If there is a w/a, can you please post it here. thanks, B.
We presented our first 'BV via RA' today and it went over huge! HUGE!

With regard to the initial post, this is fixed in 7.6.5

Dan, i just upgraded to 765 and tried it and i got 'failed to retrieve values', still.
Did you install the new ibiapplets.txt that was the 'workaround'?

Any updates on this, I am having the same issue.. Anyone else have a solution?
what is the workaround for this? Is this documented some where?

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

i remember using the ibiapplets.txt thta was sent to me by CSS, and i remember it working on 765, but we've moved on to Reporting Objects with lots of fex-y bits in them, so Business Views aren't on our list. We use RO's and rename and hide fields using the technique in tech memo 4550
or http://documentation.informati....htm?url=topic74.htm