I'm doing a report from our database regarding some amount
It shows like this in the report from the front end
however in the backend it's like this
It seems that the system adds a decimal point before the last two digits of the entries I've check the other ones and this seems to be the case
My question is, is there a function that I can use to append a decimal point before the last two digits whenever I generate the report in postgres?or is there another way to achieve the same result?
So I can provide a backend report that shows the same as the front end
Assuming the amount values are actually in cents, you should be able to just divide by 100:
SELECT expense_date, CAST(amount / 100.0 AS money) AS money
FROM yourTable;
Also, you may wish to handle this formatting issues in your presentation layer rather than directly on Postgres.
Related
I have a database lookup step that is retrieving 3 fields from a SQL Server table. One of the fields is a decimal (8,6). When retrieved, the field values appear to be integers, losing all decimal places. I have spent several hours trying to resolve this issue and have found a reference to using an alter step to ensure the decimal places are available.
In the database lookup step I have tried different data types (number, string etc.) and I've followed this with a select values step, where I'm altering the field to a number field with decimal places. Nothing has worked, so any help with what I'm sure should be a simple problem to solve would be greatly appreciated. Apologies if the answer is obvious and I've missed it.
The Group By step has a similar issue when the Sum function is used, it uses a new mask that rounds up the number, thuough in the Group By case it is just a mask. I usually fix it using a Select Values step, altering the meta-data to Number, precision 2, format 0.00 and expliciting the decimal sign, like so:
Note that the decimal sign shown in the format does not alter the decimal sign to a dot, it's just a mask.
I am having some issues dealing with numeric columns and data stored in tables. The columns are of type Number(14,2). If there are any decimal digits in numbers (like 1234.65) then it works fine. But when the numbers like 1234.00 are stored the decimal zeroes are removed when stored in tables. Another case is when numbers like 1234.50 are stored it stores as 1234.5
This is causing issue when I am retrieving the values, it is not consistent when it is displayed on User screens. We are handling the decimal digits based on flag whether to display or not. When chosen to display the number wont align because of this mismatch stored in database. The UI would display like this.
0
0
14922.9
14922.9
14922.93
But I want it to look like this if I wanted to show values after decimal point -
0.00
0.00
14922.90
14922.90
14922.93
This can be fixed on UI side, but the problem is every application using this table has to fix on its own UI part. We have a SQL view which is reading this table.
So I was wondering if there a way to fix this from SQL side and can be handled in SQL view query.
Any help is appreciated.
You can use the number format when select the values:
SELECT TO_CHAR(number, '90.99')
FROM DUAL;
http://docs.oracle.com/cd/E11882_01/server.112/e26088/sql_elements004.htm#SQLRF51075
Let's cast first before using the string function to make sure we have correct numeric type.
SELECT TO_CHAR(CAST(0 AS NUMERIC(10,2)), '9999999999990.99') AS output
FROM dual;
I need to do some very precise reporting in SQL Server Reporting Services. I'm actually attempting to show 13 decimal places. The odd part is even when I format the field C13, Reporting Services seems to round after an arbitrary number of total digits rather than anything to do with the format string.
For example if I have:
1000.01234567890123
What I end up with is:
1000.0123456789000
If on the other hand I have:
10.01234567890123
What I end up with is:
10.01234567890100
So it appears that I only end up with 15 actual digits from my source number. Has anyone seen this before, or know how to resolve it?
It sounds to me like you are using the Float datatype. Instead, I would suggest you use the decimal data type instead. You'll probably want to use something like Decimal(20, 14). You'll still need to be very careful about the math you perform because SQL Server will modify the resulting data type when you perform math on decimals.
Actually, I found the problem was Microsoft's Double.ToString() method. I had to use a "G13" as a formatting string to get all of the decimal places. Go figure.
We have SQL Server 2000 database with money data type columns and we have strange problem with numbers within money columns in which we store numbers with 2 decimal places. For o long time everything was OK. But now I see that in some rows where was number 47.22 is now number 47.2178. When i select CAST(COLUMN as CHAR) result is 47.22 but when i retrieve value from ADO recordset i have result 47.2178. I browse all application if there is any place where it can write number with 4 decimal places and find nothing(and in application history log there are records that application writes 47.22 to database). Can it be some SQL Server problem?
edit:application is written in VB6
Are you actually using the money data type or are you using a floating point type?
What happens when you use enterprise manager to select from that table? Does everything look ok?
My guess is that you are converting the data to a floating point type somewhere along the way. Probably in the ADO code.
UPDATE
Per MS: When casting money to a string type, the machine's locale comes into play. Which is why it is rounded to 2 decimal places.
You have three options.
First cast the money type to an equivalent decimal then cast that result to a char
Change the machines Regional Settings to default to the format you want.
Don't use the money data type to begin with, just use a decimal.
Don't use Enterprise Manager to draw any conclusions on what is really stored in your tables. EM has sometimes its own opinion on how to interpret data.
Looking at your CAST(....to CHAR) the reason is explained in the documentation (look for CAST & CONVERT)...
The following table shows the values
for style that can be used for
converting money or smallmoney to
character data.
Value Output
0 (default) No commas
every three digits to the left of the
decimal point, and two digits to the
right of the decimal point; for
example, 4235.98.
1 Commas every
three digits to the left of the
decimal point, and two digits to the
right of the decimal point; for
example, 3,510.92.
2 No commas
every three digits to the left of the
decimal point, and four digits to the
right of the decimal point; for
example, 4235.9819.
EDIT: Finally figured out how to use the BlockQuote feature. :-)
I'm working on a query which returns numeric values (currency). Some of the values are whole numbers and are being displayed as 3, 5, 2 etc whilst other numbers are coming up like 2.52, 4.50 etc.
How can I force oracle to always show the decimal places?
Thanks
TO_CHAR(pAmount, '9,999,999.99');
http://www.techonthenet.com/oracle/functions/to_char.php
http://www.ss64.com/orasyntax/to_char.html
To enhance the answers already given, you can use:
TO_CHAR(your_value,'fm999.99') to prevent leading spaces
____3.45 becomes 3.45 (_ indicates whitespace)
TO_CHAR(your_value,'fm990.99') to force values less than 1 to show a leading zero
.52 becomes 0.52
TO_CHAR(your_value,'fm990.00') to force 2 decimal places, even if 0
6.3 becomes 6.30
(TO_CHAR(your_value,'fm990.00')||'%') to add a percentage sign
18.6 becomes 18.60%
source: https://community.oracle.com/thread/968373?start=0&tstart=0
The display and formatting of the data should be handled at the presentation layer - not the data one.
Use the facilities provided by your front end to format the values as you see fit.
The to_char fixes the decimal issue but you have to be certain about the length. If it is longer than the format provided, it will show the number as ####. If the number is shorter, then it will leave spaces before the number. e.g
to_char(123.45),'99.00') will show ####
and
to_char(123.45),'999999.00') will show ' 123.45'.
So, if you have to export the results to CSV or Excel, these numbers will be treated as string.
So, I have not found any solution to it.
In SQL*Plus you can use the COLUMN directive to specify formatting on a per-column basis, separate from the query itself. That way you keep your query "clean" for possible other uses and still get your formatting. (In SQL*Plus at least...)
e.g
COLUMN SAL FORMAT 99,990.99
Google for "SQL*Plus User's Guide and Reference" and you should get links to the Oracle location for your Oracle version. 10.1 is here if that'll do. They'll probably all be about the same, mind you: I don't think SQL*Plus has changed much since I learned it in 1988 on Oracle 5.1.17...