iReport java.lang.Float hide decimals if zero - ireport

From IBM iSeries DB2 I recieve a ordered quantity DEC 11,4.
In iReport I use java.lang.Float to print the value. Also I have a pattern #,##0.0000;-#,##0.0000 (4 Decmimal places, 1000 separator).
When something is ordered in Metric Tons, this is no problem, but when something is ordered in pieces, it also prints "2,0000". This is confusing, how do I hide the ",0000"?

You can use two fields (Text Field, for example) for showing value. You can set visibility for fields (with help of "Print when expression" property) - show one field with #,##0.0000 pattern (for metric tons) and hide another with #,##0 pattern (for pieces).
Expression can check parameter or field, for example:
$F{valueUnit}.equalsIgnoreCase("metricTon")

Related

Calculated Field Expression, sum of field with specific values

I have a Feature field that has 4 different values (Features 1-4). There's also a use case field that has a set of values (usecase 1-4) and another set of values (usecase 5-8).
I would like to find the sum of (usecase1-4), that also contains feature1-2 from the Feature field. Same with (usecase5-8) that contains feature3-4.
screenshot for a visual:
enter image description here
How would I accomplish this?
I tried sumOver(sum(count, [Feature], [usecase])) but that gave me the same numbers of the total column. Am I thinking about the partitions wrong?

Solr fields sorting by 2 fields treated as one

I am bit struggling with one topic for custom fields.
By default all documents have field price_double to keep default price.
Next I got requirement that there should also be customer prices defined per document, so I have added fields like price_[customerId]_double next to default one.
These fields are optional and number of these fields per doc varies. When I get documents, if custom one exists I fetch it as default and use on storefront. that functionality is handled in app code.
Then I got requirement about sorting and treat price as ranged facet. But to have same behavior like custom price is default. Meaning, when I sort default and custom prices these 2 fields should be treated as one so result may look:
Custom - $1
Default - $2
Default - $3
Custom - $4
Same with range faceting. Do you have any hints how to tackle that?
Thank you a million.
And the winner is method which I posted in comment:
if(exists(price_[customerId]_double),price_[customerId]_double,price_double)
Keep in mind that if works with boolean/integer/double values. Does not work with string and texts.

OBIEE - Showing the Display Value from a Double Column / Presentation Variable

I have a double column laid out as so:
Display Value Code Column
Apr-17 201704
May-17 201705
Jun-17 201706
A 'between values' prompt is setup to show the Display Value and Filter by Column Code, and it's been given a presentation value.
So say I selected Apr-17 to Jun-17, the presentation value displays Apr-17,Jun-17 in the narrative, however I'd prefer it read like Apr-17 to Jun-17
I'm unable to use the SUBSTRING function in the narrative, so I decided to add the presentation value into a column and work from there.
However, once I add the presentation value the Column Formula, it displays the Code Column values instead of the Display Values, so:
201704,201706 instead of Apr-17,Jun-17
Is there a fix for this, or an alternative way of getting the desired formatting?
First of all your filtering seems extremely standard so I question your use of presentation variables in the first place.
If you just use out-of-the-box filter functionality with columns then you can just use the filters view.

Search operator trigger field validation in Filemaker

I'm having a bit of trouble with searching with search operators in validated fields in Filemaker Pro 13.
I have a field which has validation "numeric only", since it stores a numerical value. However, when I enter find mode I cannot use one of the pre-defined search operators such as * for "zero or more characters" or even # for "any one digit".
When I enter one of these operators in the field and try to search, Filemaker gives me a validation error and says that the field contents has to be numerical.
Is there a way to get around this problem?
That's irritating.
I just:
Created a test file
Created a Number field
Added the Strict data type option and set it to Numeric Only
Made sure validation was set to Only during data entry which should not engage in find mode
Created a couple of records and inserted values into the field
Performed my find for * and got the same error message
This feels like a bug in FileMaker to me. I don't remember running into it in previous versions, but it could be there too. I would not consider Find Mode a data entry mode so you'd think the validation rules wouldn't apply.
All that said, you could use a calc field as a work around.
Crate a calculation field in the same table and name it yourfieldnameSEARCH, e.g. idSEARCH. The calculation for the field can just be the field you actually want to search on:
e.g. `mytable::idSEARCH = mytable::id`
You can set the index to All for the calculation field so that the searching is faster. Since the calculation field is in the same table as it's reference, modifications to the original field will be reflected in the calculation automatically.
Now you can search in the SEARCH specific field without the validation being applied.
As far as the "bug" itself, you can submit it to FileMaker and maybe they'll take care of it or at least explain why it's happening.
This is true going back at least as far as FileMaker 11.
The problem is that * and # are placeholders for characters in strings. The numerical operators, <, >, <=, >=, ... work just fine even with a strict data type of numeric only. = will also work to find blank values.
For a true numeric field, however, these should cover most of your searches:
To find blank values, search for = in the numeric field.
To find all non-blank values, search for = in the numeric field and click omit on the record.
To find values between x and y use x...y in the search field.
Replicating the # operator is trickier. You could possibly replicate it with a new field that calculates the mod of a number or converts the numeric field to a string and get's the nth character.
Apparently, this form of validation is intended for Text fields.
Note that most find operators do work, despite the validation: =, ==, !, ?, ... and all the comparison operators < > ≤ ≥.
If there is a bug here, it concerns the # operator, which Filemaker expressly designates to find "one or more digits in a number field".
Two possible workarounds:
Change the field's type to Text (note that this may affect the way the field is sorted);
Replace the strict numeric type validation with validation by calculation.

Split a Value in a Column with Right Function in SSIS

I need an urgent help from you guys, the thing i have a column which represent the full name of a user , now i want to split it into first and last name.
The format of the Full name is "World, hello", now the first name here is hello and last name is world.
I am using Derived Column(SSIS) and using Right Function for First Name and substring function for last name, but the result of these seems to be blank, this where even i am blank. :)
It's working for me. In general, you should provide more detail in your questions on places such as this to help others recreate and troubleshoot your issue. You did not specify whether we needed to address NULLs in this field nor do I know how you'd want to interpret it so there is room for improvement on this answer.
I started with a simple OLE DB Source and hard coded a query of "SELECT 'World, Hello' AS Name".
I created 2 Derived Column Tasks. The first one adds a column to Data Flow called FirstCommaPosition. The formula I used is FINDSTRING(Name,",", 1) If NAME is NULLable, then we will need to test for nullability prior to calling the FINDSTRING function. You'll then need to determine how you will want to store the split data in the case of NULLs. I would assume both first and last are should be NULLed but I don't know that.
There are two reasons for doing this in separate steps. The first is performance. As counter-intuitive as it sounds, doing less in a derived column results in better performance because the SSIS engine can better parallelize the operations. The other is more simple - I will need to use this value to make the first and last name split so it will be easier and less maintenance to reference a column than to copy paste a formula.
The second Derived Column is going to actually perform the split.
My FirstNameUnicode column uses this formula (FirstCommaPosition > 0) ? RTRIM(LTRIM(RIGHT(Name,FirstCommaPosition))) : "" That says "If we found a comma in the preceding step, then slice out everything from the comma's position to the end of the string and apply trim operations. If we didn't find a comma, then just return a blank string. The default string type for expressions will be the Unicode (DT_WSTR) so if that is not your need, you will need to cast the resultant into the correct string codepage (DT_STR)
My LastNameUnicode column uses this formula (FirstCommaPosition > 0) ? SUBSTRING(Name,1,FirstCommaPosition -1) : "" Similar logic as above except now I use the SUBSTRING operation instead of RIGHT. Users of the 2012 release of SSIS and beyond, rejoice fo you can use the LEFT function instead of SUBSTRING. Also note that you will need to back off 1 position to remove the comma.

Resources