In a CDS View select statement, given that I have a column of type DEC, how do I convert that to type INT?
Work done so far: According to the CAST_EXPR documentation, this is not possible with CAST_EXPR . According to the numeric functions documentation, math functions like FLOOR will return a value of the same type.
Update: the numeric functions documentation is correct.
The code floor(fieldname) will convert a DEC(X,Y) (where Y > 0) into a DEC(X,0). Essentially, floor strips the decimal places from the field without changing its type.
On the other hand, ceil(fieldname) will round up to the nearest integer and convert a DEC to an INT
If you want to get an integer from the floor function, then you must call ceil(floor(fieldname))
On a NetWeaver system, you should be able to find the CDS View demo_cds_sql_functions_num and program/report demo_cds_sql_functions_num that help demonstrate these concepts. You can use the debugger to view the report's variable result and confirm my findings.
ceil does it:
cast(ceil(fieldname) as abap.int4)
Note that floor won't.
Related
I am a somewhat newbie to SQLite (and KMyMoney). KMyMoney (an open source personal finance manager) allows one-click exporting data into an SQLite database.
On browsing the SQLite database output, the dollar amount data is stored in a table called kmmSplits as several text fields in a strange format based on “value” and “valueFormatted” (see screen shot below). The “value” field is apparently written as a division equation (in a text format) which apparently yields the “valueFormatted” field (again in text format). The “valueFormatted is the correct number amount but the problem is that parenthesis are used to indicate a negative number instead of a simple minus in front of the value. This is apparently an accounting number format, but I don’t know how to parse this into a float value for running calculated SQL queries, etc. The positive values (without parenthesis) are no problem to convert to FLOATS.
I’ve tried using the CAST to FLOAT function but this does not do the division math, nor does it convert parenthesis into negative values (see screen shot).
The basic question is: how to parse a text value containing parenthesis in the “valueFormatted field (accounting money format) into a common number format OR, alternatively, how to convert a division equation in the “value” field to an actual calculation.
Use a CASE expression to check if valueFormatted is a numeric value inside parentheses and if it is multiply -1 with the substring starting from the 2nd char (the closing parenthesis will be discarded by SQLite during this implicit type casting):
SELECT *,
CASE
WHEN valueFormatted LIKE '(%)' THEN (-1) * SUBSTR(valueFormatted, 2)
ELSE valueFormatted
END AS value
FROM kmmSQLite;
Or, replace '(' with ''-'' and add 0 to covert the result to a number:
SELECT *,
REPLACE(valueFormatted, '(', '-') + 0 AS value
FROM kmmSQLite;
I am new to Pentaho, so please be gentle.
I am, perhaps naively, wanting to use a Formula to convert a six-character string in the form YYYYMM to the date representing the final day of that month.
I imagine doing this step by step using successive lines of the Formula: checking that the string is of the correct length and, if so:
extracting the year and converting it to integer (with error checking)
extracting the month and converting it to integer (also with error checking)
converting ([year], [month], 1) to a date (the first of the month)
adding a month
subtracting a day
Some of those steps may be combined but, overall, it relies on a succession of steps to achieve a final result.
Formula does not seem to recognise the values achieved along the way though, at least not by enclosing them in square brackets as you do with fields from previous objects in the mapping.
I suppose I could have a series of Formula objects one after the other in the mapping but that seems untidy and inefficient. If a single Formula object cannot have a series of values defined on successive lines, what is the point of even having lines? How do I use a value I have defined on a previous line?
The formula step isn’t the best way to achieve that. The resulting formula will be hard to read and quite cumbersome.
It’s better (and faster) to use a calculator step. A javascript step can also be used, and it will be easier to read, but slower (though that probably won't be a major issue).
So, one way forward is to implement this on a calculator step:
Create a copy of your string field as a Date
Create 2 constant fields: 1 and -1
Add 1 month to the date field
Subtract 1 day to the result
Create a copy of the result as a string.
See screenshot:
I have an exponential value for e.g. 3.22122E+23
In Marklogic when I try- xs:decimal(3.22122E+23)
I get this error:
[1.0-ml] XDMP-CAST: (err:FORG0001) xs:decimal(xs:double("3.22122E23")) -- Invalid cast: xs:double("3.22122E23") cast as xs:decimal
A lower value for e.g. xs:decimal(3.22122E+18) gives me the correct result i.e. 3221220000000000000.
I see that this is because of decimal overflow and cannot be represented as a decimal data type but is there any way in Marklogic to handle and calculate such huge values?
Same question applies for the negative values(3.22122E-23) where I can handle and display data above 20 decimal places.
It would be helpful to clarify what kind of logic or calculations you are trying to accomplish and why exactly you need to convert the value to decimal. For example, to "display" the double value, you can use the standard format-number function without any conversion to decimal:
let $x := xs:double(3.22122E+23)
return format-number($x,"#,##0.00")
yields:
322,122,000,000,000,000,000,000.00
See https://docs.marklogic.com/fn:format-number for details regarding fn:format-number() usage.
See https://help.marklogic.com/Knowledgebase/Article/View/487/0/marklogic-server-and-the-decimal-type-implementation for details of the limitations of the xs:decimal type.
In R for Everyone by Jared P. Lander on p. 54 it says "...NULL is atomical and cannot exist within a vector. If used inside a vector, it simply disappears."
I understand the concept of being atomic is being indivisible and that NULL represents "nothingness", used commonly to handle returns that are undefined.
Therefore, is NULL atomical b/c it has this one value always of "nothingness", meaning something simply does not exist and therefore R's way of handling that is to just not let it exist in a vector or on assignment in a list it will actually remove that element?
Trying to wrap my head around it and find a more intuitive and comprehensive answer.
In my opinion talking about vectors as being "atomic" is more confusing than helpful. Instead, consider that R has a series of data types built into the language. They are given by definition and are distinct from one another.
For example, one such data type is "integer vector", which represents a sequence of integer values. Note that R does not have a data type of "integer". If we are talking about integer 5 in R, it is actually an integer vector of length 1.
Another built-in data type is NULL. There is a single object of type NULL, which is also called NULL. Since NULL is a type and an object, but not an integer value, it cannot be part of an integer vector.
Missing data in an integer vector are represented by NA. In this context NA is considered an integer value. Note that NA can also be a numeric value, logical value, etc. NA is a not a data type, but a value.
A complete list of built-in data types can be found in the R source code and also in the documentation, e.g. https://cran.r-project.org/doc/manuals/r-release/R-ints.html#SEXPTYPEs
I want to limit numeric column type to 10 symbols before decimal separator and 4 symbols after decimal separator. I executed the following command:
ALTER TABLE scustdisc ADD COLUMN spec_price numeric(10,4)
The command executed without errors but when I try to insert value in spec_price 10.123456 I am able to do it. It should give error and the value not to be inserted. Am I wrong in my alter command?
SQLite has a dynamic type system and the column types have a limited impact, but can be virtually any name. They are resolved to one of TEXT, NUMERIC, INTEGER, REAL or BLOB.
numeric(0,0) - numeric(99999999,99999999) and more resolve to NUMERIC.
As such 10,4 4,10 etc means nothing and makes no difference to SQLite.
With one exception bar constraints a column may hold any type of value. The column type only comes into play in determining the way the data is stored.
A must read is Datatypes In SQLite Version 3
You may also find How flexible/restricive are SQLite column types?
You may be able to resolve this by using a CHECK constraint CREATE TABLE or by using a TRIGGER or multiple TRIGGERs.
You could format the number(s) appropriately when they are displayed.
You could utilise the round(x,y) function Core Functions