Welcome to the Oracle Analytics Community: Please complete your User Profile and upload your Profile Picture
Comments
-
This would be extremely useful - catalog management in a large organization becomes very difficult over time using only the OAS/OAC UI interface, when there are hundreds of folders and thousands of reports. Need to have better ways to access this information that is native to the UI.
-
100% agree - this is a frustrating functional gap that has caused many problems when you have multiple environments using different connections. Importing projects should be able to use connections in the target environment without entering any passwords.
-
As an internal implementer of OAS, I can say this is an often-requested feature from our customers. We've implemented manual workarounds for it at the database level but having it on the Datasets themselves is the ideal solution.
-
Our customers are also asking for this, currently it's difficult to manage datasets and data flows in a large organization.
-
This is a really important issue - our user base is constantly frustrated with the errors and lack of complex SQL support in the dataset creator.
-
We're using embedded DV projects with an internal JET-based product and the lack of DV URL parameters (or even params passed into the embedding code) is a major limiting factor for us.
-
This would be a great improvement - right now we are embedding some DV projects in a custom JET application, but the inability to pass in filter values to the DV embedding functions makes it less useful.
-
This is a frustrating usability issue - a workaround that has been used to deal with this issue is to create new calculations every time a user needs to have a custom headers. Very tedious and time-consuming.
-
Getting data out of DV is already quite limited compared to OBIEE, this usability change would definitely help simplify things for all users. Almost every user will at some point need to copy data into Excel or other apps from DV.
-
Strongly agree - out customers like the idea of Data Actions/drilldowns in DV but it needs refinements like this one to make the final experience clean and simple.
-
+1. We have seen the same issue, and multiple customers of ours will need this to work to make full use of DV in reporting.
-
This would make tiles a lot more useful, and this is functionality they basically already had in the old Mobile App Designer, so the current tile implementation was a big step backwards.
-
Excel is used almost exclusively to export Answers/Dashboard reports across all of our customers/users, the same level of support needs to be included in DV.
-
Strongly agree, calender filters in DV are too limited, especially when using a Fiscal Calendar which makes heavy use of RPD variables and objects. Also need the ability to disable the "auto" setting when using expression filters or variable filters, it really should be None by default.
-
Taking away the link between Classic and DV makes it feel like two isolated applications, not a unified/modern SaaS experience. It's a simple thing but it impacts user perception a lot.
-
Very desirable feature. Presentation/request variables passed between prompts and analyses is very common for our implementations and moving such analyses into DV is not possible without this.
-
Thank you Jerry (and everyone), that is a nice trick with EVALUATE. I think that would solve the problem I had with RANK. As Robert said though, this is also a case of replicating an Excel sheet in OBIEE, which can be a painful/pointless exercise, so I will have to expand on these points and see how it goes.
-
Unfortunately, pivot tables don't appear to work if a RANK() is the defining attribute, it recalculates the rank on the fly using whatever else is in the pivot table with it (in this case, there's no other attributes shown if i want it to group by rank). Even if a simple table displays the two result sets from the UNION…
-
I don't believe AGO will help this case though? There is no LY data for the TY items (and vice versa), I need to compare the sales of whichever items were in each ranked position during their selling period. If TY and LY are simple measures, they would both operate on the same item on each row, unless there's a trick to…