I have noticed that the default for grabbing a column/row in MDX (generated from Excel) is:
SELECT
NON EMPTY {
...
} ON COLUMNS,
NON EMPTY {
...
} ON ROWS
FROM [Model]
Why is this the default behavior? When would empty columns or rows come up in actual usage?
Also, it says NONEMPTY is the correct name in the docs, but when I use that I get a syntax error. What's the difference between NONEMPTY and NON EMPTY -- is one deprecated?
As you found in documentation Nonempty is the function so it will need brackets around set expression: NONEMPTY(set_expression). NON EMPTY is the keyword.
The big difference between the NON EMPTY keyword and the NONEMPTY
function is when the evaluation occurs in the MDX. The NON EMPTY
keyword is the last thing that is evaluated, in other words after all
axes have been evaluated then the NON EMPTY keyword is executed to
remove any empty space from the final result set. The NONEMPTY
function is evaluated when the specific axis is evaluated.
Related
Filtering by a second column removes the filter from the first column, Ag Grid, Vue. How can it be avoided?
I would like to be able to filter by more than one column.
I am using the server side rendering. I found out the framework code which is responsible for checking if there is a filter applied (and if this code piece tells that a filter is not applied, then the respective filter gets removed):
SetValueModel.prototype.isFilterActive = function () {
return this.filterParams.defaultToNothingSelected ?
this.selectedValues.size > 0 :
this.allValues.length !== this.selectedValues.size;
};
In my case I did not set the defaultToNothingSelected, it is undefined, so it results in a falsy value. But since I update my set filter values after running the filter, the this.allValues.length becomes equal to the this.selectedValues.size, which results in the isFilterActive returning false.
So far the two solutions I see are to either set the defaultToNothingSelected to true or do not remove the available filter values after the filtering was done. I remove them using the api.getFilterInstance(colId).setFilterValues(values).
By removing the filter values I mean the following:
A column has the a, b and c values. I filter by a. Now I set the available filter values to be only a. Probably I should not be doing that.
I still hope to find a cleaner solution, so let the question hang here.
I need to minus some value (value coming from DB though Databean and VO) here is my code:
value="200 - #{pc_costReportDataBean.adjustCostVo.explanationLength}"
but the problem is result coming like [200-0].
Try:
value="#{200-pc_costReportDataBean.adjustCostVo.explanationLength}"
The #{} means that the whole expression inside will be evaluated. The values outside will be just treated as Strings.
I have a dataset with columns containing numbers. However, some of the rows in that column have missing data. Instead of numbers, a dash (-) is placed in the cell.
What I want to happen is to separate those rows with a dash and output them to a separate excel file. Those without the dash, should output to a csv file.
I tried the "filter rows" but it gives me an error:
Unexpected conversion error while converting value [constant String] to a Number
constant String : couldn't convert String to number
constant String : couldn't convert String to number : non-numeric character found at position 1 for value [-]
My condition is if
Column1 CONTAINS - (String)
You cant try to convert to number in the select step,and handler the error, if can not convert to number that mean that is (-)
You can convert missing value indicators (like a dash or any other string) to null in Text-File-Input - see field option "Null if". That way you still can use the metadata detection feature and will not trip over a dash arriving in a Number field.
With CSV-File-Input you should stick to the String datatype until a Null-If step has cleansed the values, so you can change the datatype to Number in a Select-Values step.
If you must preserve the dash character, don't use metadata detection (as it suggests datatype Number) or use more rows to sample (so a field with a dash is encountered) or just revert the datatype to String again before saving and running the transformation.
My solution lies on the first 'Replace in String'. I replaced the dash into something numeric and can easily be distinguished from the rest of the numbers (I used 9999) and carried on with the rest of my process.
In filter rows, I had no problems anymore with the data type because both my variables and condition contained numbers, therefore, it no longer had to convert anything.
After filter rows, I added the 'Null-if' to remove the random 9999 that I used
just to have something to replace the dash.
After that, the separation was made just as I hope it would.
Thanks to #marabu for the Null-if idea.
The following code is showing result as Nan% if values are zero:
=FORMAT(((Sum(IIF(Fields!flag.Value=1,CINT(Fields!area1.Value),0)))
/ (Sum(IIF(Fields!flag.Value=1,CINT(Fields!UnitArea.Value),0))) *100),"N") + "%"
The simplest way to avoid the divide by zero error here is to not create it in the first place! If you replace the 0 as second return value in the divisor Iif expression with a 1, then the problem goes away.
That said I think your whole expression could do with simplifying somewhat. If I read it correctly you want to determine the proportion of area1 within UnitArea but only when the value of flag is 1. The expression could be thus written:
=Format(
Iif(
Fields!flag.Value = 1,
CInt(Fields!area1.Value) / CInt(Fields!UnitArea.Value),
Nothing
),
"Percent"
)
Note that I've dropped the multiplier and instead used the Format function to return the result of the division as a percentage (you could also simply further by removing the Format function entirely and handling the formatting in the designer).
You don't have to layout the expression with indentation as I have, but the expression builder ignores the whitespace and it does make larger expressions easier to read, so I think its a good habit to get into.
I'm trying convert WMB 7 mapping nodes to IIB 9 nodes. The auto-convert process turns some ESQL functions to XQuery functions.
Specifically, it turns the ESQL function
COALESCE (var0, var1)
(which returns the first non-null value, as in if var0 = null then var1 else var0) into
XQUERY (var0,var1)
Is it a correct conversion?
If it is, can someone provide a link to API? I couldn't find this on XQuery syntax and operators manuals.
XQuery is not an API, but a standard, and the full syntax can be found online: XQuery 1.0 and XQuery 3.0 (there is no 2.0). You'll also find many manuals, tutorials etc.
XQuery relies on XPath, which is even wider used than XQuery and can be found in libraries for almost every general purpose language.
Your expression is correct XQuery, in that it considers everything a sequence, and the comma concatenates (and flattens) two sequences.
XPath does not know NULL, but it knows xsi:nil and (), the latter being the empty sequence. An empty sequence is removed from the result.
I am not sure what XQuery processor is used underneath, but the correct expression should be ($var0, $var1)[1]2, which works the same way as your COALESCE operation1. In XPath and XQuery, variables are referenced with the $ sign. The number of variables or expressions separated by the comma is unbounded. If all are the empty sequence (null), the result is the empty sequence.
Without [1], it will return all items that are non-null and discard the rest. You can use another index, like [3] to get the third non-null value. If no such value exists, it will return null (empty sequence).
1 which behaves not exactly the way you described it. I believe it behaves like if var0 == null then var1 else var0, it selects the first non-null value (I've updated the OP).
2 as Florent has explained in the comments, a warning with this expression is in place. If you have $var1 := (1, 2) and $var2 := (3, 4), the expression $var1, $var2)[1] will return 1, not (1, 2), because sequences cannot contain subsequences, and indexing a sequence with [x] will return the xth value of the flattened sequence. You can safe-guard your expression with (zero-or-one($var1), zero-or-one($var2))[1].