I'm trying to replicate a report from old Oracle Discoverer to OBIEE.
The issue is that when I had the "pivot table prompts" to the OBIEE analysis. I'm left with duplicates instead of unique values in the drop down field. Can anyone explain how I can keep this from occurring? This only happens when I add three or more attributes/columns to the "pivot table prompts" section. This worked in Oracle Discoverer….
Be sure, for the physical connection you have defined, that you have checked the below option:
Also, I know there was a bug around this sort of functionality occurring if the column properties were set to repeat, but that is not a common thing people do, and is probably not your scenario, but it is worth a look: Bug 13147411 : 11G PROMPT IS DISPLAYING REPEATING VALUES WHEN ITEM PROPERTIES SET TO REPEAT
As mentioned by rmoff, incorrect keys can often lead to this issue. As he said, you can check the nqquery.log to see the physical SQL, or enter SET VARIABLE LOGLEVEL=4; in the SQL prefix on the advanced tab, then run your report again. This will generate a log in the admin pane of the tool that you can check easily.
The dropdown list is built from the dimension you have defined, so if your key is incorrect you'll get duplicates. Check the physical SQL in nqquery.log if in doubt to see what SQL OBIEE is generating that returns the duplicates, and make sure you have defined your logical dimension correctly.
The issue was resolved by moving "Repeat" to "Suppress" for the individual columns that I was prompting on in the pivot!
We did this a lot throughout my department because we use the exports for further manipulation rather than using OBIEE only for high level overview and summation. Each row must hold the value in order to filter, so the "Repeat" functionality is often selected.
Thanks for the help/answer!!!
Related
I'm using MS-Access (365) as a frontend to a Postgres table backend. Communications mech between them is ODBC. That seems to work fine.
Before I migrated away from the MA-Access backend, a list of check-able options would appear in a column's filter options when filtering column data. For example, when you clicked on the little carat next to the column name/header, you would see the "Sort A to Z" and "Sort Z to A" (as before) then for the filtering, you would see "Text Filters" as before (with options for specifying the filtering), but then you would also see the options, including "Select All" (a toggle) and then each value with a checkable box next to it. The user could select/deselect to filter based on the values. But I no longer see that list of checkable values in the filtering.
The column values are constrained to values in a different table which contains the valid values for that column (a traditional primary/foreign key relationship) and that works fine in the pulldown as a means for a user to pick one of the valid values when editing a record/column.
Since the values of the column are constrained in a predictable, or at least queryable way, I would think that there might be a way to use that to restore those checkable boxes in the filtering. I looked at the "Design View" of the table and tried a few things to see if I could get this to work. No luck.
Any ideas ?
You can try this setting:
File->options->Current Database-> Filter lookup options.
the real problem here is that you really should not be loading up forms with SO MANY records in the first place. But you can try the above settings - and of course increase the 1000 rows. But this is going to cause a performance issues, since this suggests that forms and view are loading large recordsets and THEN you are applying filters to that data. So keep this pulling of data in mind. It is preferable to provide some kind of search form, and let the user search BEFORE you pulled large amounts of data.
So all in all this is a less then ideal option from a performance point of view. But if data pulls are not too large, then this certainly is a "nice" feature - just not a great from a performance point of view.
I have a SQL Server that is ODBC into my Access which is being utilized as my front end. I created a column in SQL with a BIT data type and created a checkbox with the yes/no data type that uses my SQL Column as its control source. When I go into my form and try to change anything in there and update my tables, I get a writing error and it wont let me append the updates I'm trying to make. As soon as I delete the bit data type, and the check box, then I am able to again append information to my form. Does anyone know a solution or a way I could utilize the Boolean check boxes to report to my SQL Database so that I could track progress of an order, but still be able to append my records? Also if anyone knows why this is happening I would appreciate the information just for my own notes and understanding.
this image shows the column created in SQL Server
This image shows what it looks like in the ODBC table in Access
This image shows the control source I picked which is from a query that utilizes the names of the form comboboxes, text boxes, and hopefully check boxes
This is image shows what happens after I try to update and and close
Thanks
haven't done this for a long time, but the problem could be related to the numbers that are stored. yes/no in access = -1/0, in sqlsrvr = 1/0 (or similar). you could use an INT field in sqlsrvr which will then store whatever access sends (-1 or 0), or keep the BIT but don't use yes/no in access - create a custom yes/no table where yes=1 and no=0 (or whatever BIT needs) and use the custom table as a lookup table for that field which, when updated will send the appropriate value. hope that's all relevant and makes sense.
So I have been messing around with this and after a few other problems running through SQL, Cabinet Vision (our drafting software with a ancient access database) and crystal reports I came to realize that Access cannot accept null values.
So in my SQL Bit data type column I set the default value as 0 and didn't allow nulls. now it records all my check boxes as true or false. and I no longer have a write conflict.
This most commonly arises when a db is developed in Access and at some later date the tables are exported via ODBC to SQLServer. The Checkbox controls on the Access forms were probably placed there using the 'Available Fields' button on the Access 'Design' ribbon. Before getting into complicated solutions with T-SQL modifications to metadata etc, try simply deleting the checkbox control from the problem Access form. Insert an unbound checkbox to replace it, then use the the Properties dialog to set the relevant SQLServer field as the control source for that checkbox. Usually works.
I'm using MS Access 2007 as a front end and have all linked tables in SQLServer 2008 R2 backend.
In a form in Access I am trying to execute the FIND button either in the ribbon or by creating a button on the form with the expressed purpose of looking for records with a specific value in a particular field.
When I complete the entry in the FIND window, I click on Find Next. In some cases, the record(s) is found immediately. In others, it can go for hours only to report that it can't find anything (when I know it should).
The table I am looking in has approximately 99,000 records in it. It doesn't seem to matter whether or not the field is indexed.
Is there something I'm doing wrong, or is Access unable to handle this? Also, is creating a stored procedure with handling multiple search requests and passing the info to Access the answer?
The find methods are known to be slow with ODBC data sources. Here is what the Access 2007 Recordset.FindFirst Method help topic says:
When working with Microsoft Access database engine-connected ODBC databases and large dynaset-type Recordset objects, you might discover that using the Find methods or using the Sort or Filter property is slow. To improve performance, use SQL queries with customized ORDER BY or WHERE clauses, parameter queries, or QueryDef objects that retrieve specific indexed records.
Futhermore, binding an Access form to a record source of 99K records is a performance challenge. Use a query as the form's record source, and design the query to return only one or a few rows.
Give the user an option to choose a different set of rows, and modify the form's record source property to reflect the user's choice.
This depends on the type of search you need and on the data type of the column (field) to be searched. For example, if I have a text data type in an indexed column and I search using Start of field or Whole field, it will be quite fast, however, if I search for Any part of field, it may well fall over. In other words, if Access can use an index for the search, it will work, even on quite a large table, otherwise, you may be best with a stored procedure, though I doubt that will be fast without an index, either.
I'm having a little trouble with the form filter in Access 2007. I'm using the listview in a few forms and the user needs to be able to filter there.
For testing purposes I made a query, which is just based on one table. If I want to set the first filter, it looks like that:
I choose a value and if I want to set another filter (on a different field obviously), there aren't values available to choose from.
This seems to happen only if I use a query (doesn't matter if I use every field, or just a few, based on one table or multiple linked tables). I can of course use the number filter and enter a value manually.
I have another database, where I can use filters when and wherever I want, regardless whether it is a query or a table - I have a list with values to choose from everytime. This means I messed something somewhere up but I have absolutely no clue where.
I'm using Access 2007 (FE/BE), if you need any further details, just ask. Any advice where to start looking is very appreciated!
Well, after playing around for a long while, I figured out what the problem is.
The form recordsource needs to be a query - no sql code, no "select * from query", just the name of a query. Anything else leads to the fact that you are limited in using the filters. I'm not sure if this is a bug or if there is a reason behind this, but that's the way it works in access 2007 - at least for me.
Before I was dynamically adding conditions to my queries which led to a recordsource like "select * from qDeliveries where location = 1". To accomplish this I now just create a temporary query which is the form recordsource instead of just using the sql code.
Hope this helps anyone... :)
Instead of using a query, try this:
File >> Options
Current Database
Scroll down to Filter lookup options
Check ODBC Fields
Close and re-open the file. That should solve the issue.
Create a Separate query and assign to that form. instead of create query within the form. Your problem might get resolved. I did the same way it's working fine for me.
I want to group by a report item, but that's not allowed.
So I tried creating a parameter...not allowed as well.
Tried referencing from footer...failed again.
This is somewhat complicated.
Let me explain:
I have textbox22, it's value is:
=Code.Calc_Factor(Fields!xx.Value, fields!yy.Value...)
This is embedded VB code in the report that's called for each row to calculate a standard factor.
Now to calculate the deviation from the standard factor, I use textbox89, whose value is:
=(Fields!FACTOR.Value - ReportItems!textbox22.Value)/ReportItems!textbox22.Value
Don't get confused between Fields!FACTOR.Value and textbox22.Value, they are different.
Fields!FACTOR.Value is the factor used, textbox22.Value is what it should be (standard factor).
Now I want to create a group which splits deviations into 2 groups, > 1% or not.
So I tried creating a group:
=IIF(ReportItems!textbox89.Value > 1,0,1)
...But then SSRS complains about using report items.
I have run into a similar problem of using report items in the past, but this is a new case!
Any help greatly appreciated.
Have you tried adding a calculated field to your dataset?
Here is how it works:
While you are in the layout view of the report, open "datasets" tool window(in my environment it is on the left).
Right click on the DataSet you are working with and add a field, you can use a calculated field, and build your formula appropriately
Then you should be able to group on this field
-Dan
I'm not 100% that someone won't have some magic solution for this but I have run across similar problems myself in the past. I believe (but could be wrong) the problem Reporting Services is having is that it only renders once and what you're asking it to do is render the data before rendering the grouping which it doesn't do.
The only way I have ever been able to produce the exact results I need is to make the data rendering happen exclusively in the SQL (through the use of table variables usually) and then use Reporting Services merely as a display platform. This will require that your factoring algorithm gets expressed in the T-SQL within the stored procedure you will likely have to write to get the data in shape. This would appear to be the only way to achieve your end result.
This has the bonus feature of separating report design and presentation from data manipulation.
Sorry I couldn't provide a SSRS solution, maybe someone else will know more.