When extracting data about an Ethereum wallet via the Etherscan.io API, after converting from JSON to CSV I end up with values like this:
562450260000000000
30174270000000000000
552758590000000000
988800000000000000
The first is 0.56245026 ETH, with a ton of trailing zeroes. The second however is 30.17427 ETH. That's the real trouble here. I can't figure out how to format this column of data so that Excel effectively starts from the right, skips the 10 trailing zeroes, then goes 8 more places, to put the decimal.
Ideally what I want to end up with is this:
0.56245026
30.17427000
0.55275859
0.98880000
The trailing truncation is easy, but placing the decimal properly (preferably without a messy formula that uses position and string manipulation for example to do it) is what I'm stuck on. Anyone know how to do that?
The huge numbers are the numbers you are looking but multiplied by 10e18.
You should just divide those huge numbers by 10e18 and you will get your desired numbers.
Related
I have numerical output from a Kusto/KQL query where I would like to format the output to have comma separations. I would also like to round to the nearest whole number. For instance, instead of 1000.2865 it would come out as 1,000. Is there any built-in KQL function to accomplish this? I checked the documentation but couldn't find it. I would hope to find something like this:
format_number(myNumberColumn, 0, "commaThousands")
Note: if it comes out as a string I'm fine with that, and I also realize the displayed output in Azure Data Explorer does visually format. But once I take the data outside of there I lose that formatting, like if I paste into Excel or use the query for a dashboard to show a key metric.
for rounding a number, you can use the round() function, the ceiling() function, the floor() function, or the toint() function.
formatting numbers, e.g. adding separating commas, would be best if done by the client application you're using to present the result (e.g. you mentioned Excel, which certainly has this feature for formatting numeric values in cells).
I'm working with latitude/longitude data in SQL that is going to be collected from a wide variety of sources with varying precision.
I'm trying to figure out a data type that will preserve trailing zeros without using decimal to set an amount of zeros. 12.345 should be different from 12.34500. Is there a way to do this without simply converting these values to character? That seems to be the obvious solution but I'm trying to get a better idea of the range of options.
If you want to preserve zeros after the decimal place -- and distinguish between numbers that are otherwise numerically equal -- then I think you need to use strings:
'12.345'
'12.34500'
My office uses excel to prepare our data before importing it into a SQL database. However, we have been expreiencing the following error.
When the data is imported from one computer it loses all of the leading zeros. However, when it is imported from a different computer it imports perfectly.
An example of the leading zeros are that our item numbers are required to be formatted as "001, 002, 003,... 010, 011, 012,... 100, 101, 102, ect".
1) The excel file is stored on a server so there is no difference in the file.
2) If the users swap workstations the result stays with the computer, and doesn't switch with the user.
3) The data is formatted as text. It has been formatted as text both from the Data Tab and from Format Cells.
Is there a setting within excel that is specific to the computer and not the spreadsheet which will affect exporting the data? Or is there a non-excel specific setting which will cause this?
Its best to avoid the 'TEXT' format option. Confusingly, it does not force the contents of a cell to be a text data type, and it wreaks havoc when a formula references a 'TEXT' format.
To add to the previous answer (with all of the caveats about if this is a good idea), you can use the TEXT worksheet function
=TEXT(A1,"000")
to guarantee an actual text string with leading zeros if needed.
Depending on number of leading zeroes that you require, you can select your data/column in Excel, go into Excel >> Format >> Custom >> type in however many zeroes you require into the Type field (i.e. 000000000 for a 9-digit number with leading zeroes), and it will automatically preface with the correct number of leading zeroes to make the numerical string the correct length (i.e. 4000 = 00004000).
Note, this only works with numerical data, not text, but depending on the scenario it may be more useful to retain your data in numerical format - the example you gave listed numerical data only, and often retaining the numerical format is a benefit for analysis.
Not sure what the benefit of padding data before inserting it into the database would be...(takes more space, slower searching, etc.). Sounds like you're formatting it for output (?), which might be more efficiently done elsewhere.
But anyway -- here are some ideas for your SELECT (sql) statement:
RIGHT(1000 + [excel field], 3)
or another one would be
REPLICATE('0', 3 - LEN([excel field])) + [excel field]
Something you can do to the Excel field itself (before import) is prefix it with a ' (apostrophe). Notice if you type 0007 into Excel, it will change it to 7, but if you type '0007, it will keep the leading zeros.
I am trying to calculate Total Sales at a store. I have product Price in a column called UNIT_PRICE. All the prices have 2 decimal places example: 34.54 or 19.99 etc and they are imported as type:float in the schema. (UNIT_PRICE:float)
When I perform the select Query: "SELECT CompanyName, SUM(Unit_Price) as sumValue" etc I get the following returned in the column, but only "sometimes".
2.697829165015719E7
It should be something like: 26978291.65
As I am piping this out into spreadsheets and then charting it I need it to be in the type float or at least represent a normal price format.
I have tried the following but still having issues:
Source: Tried converting original data type to BigDecimal with only 2 decimal points in the source data and then exporting to the csv for import into bigquery but same result.
Bigquery: Tried converting to a string first and then to a float and then SUM but same result. "SELECT CompanyName, SUM(Float(String(Unit_Price))) as sumValue"
Any ideas on how to deal with this?
Thanks
BigQuery uses default formatting for floating point numbers, which means that depending on the size of the number, may use scientific notation. (See the %g format specifier here)
We tried switching this, but it turns out, it is hard to get a format that makes everyone happy. %f formatting always produces decimal format, but also pads decimals to a 6 digit precision, and drops decimals beyond a certain precision.
I've filed a bug to allow an arbitrary format string conversion function in BigQuery. It would let you run SELECT FORMAT_STRING("%08d", SUM(Unit_Price)) FROM ... in order to be able to control the exact format of the output.
Do you see this in the BQ browser tool or only on your spreadsheet?
BQ float is of size of 8 bytes, so it can hold numbers >9,000,000,000,000...
I find it that sometimes when Excel opens a flat file (csv) it converts it to the format you mentioned. To verify this is the case, try to open your csv with notepad (or other flat file editor), before you try with excel.
If this is indeed the issue, you can configure the excel connector to treat this field as string instead of number. other option would be to convert it to string and concat "" to the number. this way the spreadsheet will automatically treat it as string. afterwards you can convert it back to number in the spreadsheet.
Thanks
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...