I'm working in Access 2010's SQL editor and I'm performing a calculation that results in a ratio.
I would like to display this ratio as a percentage using the SQL syntax editor, but as a number, not a string. I'd like to be able to paste out/export to Excel and not have to convert text to numbers.
Let's say this is my calculation:
OriginCount/DestinationCount AS MatchRate
I used the FORMAT function to make it appear as a percentage, but the result appears as a string. (Which I think is how the FORMAT function is designed to work)
FORMAT(OriginCount/DestinationCount,'Percent') AS MatchRate
Question 1: Is this possible using the SQL syntax editor?
Question 2: How do I do it?
Thanks!
How will you be using this data? It is standard to leave it as a double, EG: 0.02354, and then simply change the format of any control displaying that field.
Users should not being seeing tables or queries without them being the recordsource of a form, so this shouldn't be a problem.
That way, when exporting to Excel/Wherever else, it will properly display as a decimal number, and when viewing in Access, it will display as a Percentage 2.35%
The result of the FORMAT function in access is always in string format, so that would be expected behavior.
Did you try the CONVERT function instead?
https://msdn.microsoft.com/en-us/library/ms187928.aspx
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).
Have an issue where when a report is downloaded, a field that has over 15 digits is converted to scientific notation instead of displaying the full digits (i.e. 672000000000000 = 6.72×10 to the 14th degree). I know this is an excel feature, but is there any workaround for it on the SSRS end?
Thanks!
This is an Excel issue, not a Reporting Services one. The SSRS CSV export should contain the number as it exists in the report, e.g. 672000000000000
The default behaviour for Excel (which you are presumably using to open the CSV file) is to display values this large using scientific notation, i.e. "6.72E+14". This behaviour can't be controlled from within SSRS.
As an alternative you might consider using the Excel render method for the report, which might give you more control over the display of these numbers.
Excel won't mess with it if you convert the expression to a string within SSRS.
Go into the expression for the text box and type the following:
=Str(Fields!YourFieldHere.Value)
Is there a way for a number to stay as a number and not a string even with the percent sign?
The reason I write a function in a query like:
Format(IIf([BDE MTOE CURRENT]=0,0,[PROJECTED OH]/[BDE MTOE CURRENT]),"Percent")
is so that I can output a complete report without having to do anything to it.
Microsoft Access (My version is 2007) changes it to a string.
You do not need to format the number in the SQL query. There is a formatting option for the values in Access reports:
If you are exporting the data to Excel there is a similar option for the Excel cells.
The bottomline is: numbers should stay numbers. That way they are better manageable: you can sort them, you can apply mathematical operations on them
Agreed. I have decided to keep numbers as decimals and will format the spreadsheet columns into percentage from MS Access using VBA. I kinda hoped I could do it all from SQL.
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 am at the liberty of a certain database, which stores date values as integers (i.e. 20121119). I have several queries that retrieve these values for reporting displays, so I need to convert these values to m/d/yyyy format.
I see several ways to do this:
Do the conversion in the display, using an existing global UDF. The drawback here, is that if the query is re-used, I need to duplicate the code necessary to convert the display value.
Parse the value in the SQL to return a properly formatted value. I'm reading from a DB2/iSeries, which does not (as far as I have found) have a built-in function for this.
Loop over the result set and convert each value one at a time. This is what I am currently doing, however for larger data-sets, performance is an issue:
<cfscript>
var i = 1;
var _query = ARGUMENTS.query;
if ( !Len(Trim(ARGUMENTS.column))
|| !ListFindNoCase(_query.ColumnList, ARGUMENTS.column))
return _query;
for (i=1; i<=_query.RecordCount; i++) {
_query[ARGUMENTS.column][i] =
VARIABLES.Library.DateTime.ParseAS400Date(
_query[ARGUMENTS.column][i]
);
}
return _query;
</cfscript>
Is there an easy/quick way to apply a formatting function to an entire column in a ColdFusion query object?
As noted by #Dan, there is a built-in function that will convert a string to a timestamp representation. Since you have an int, then it would be something like this:
SELECT VARCHAR_FORMAT(TIMESTAMP_FORMAT(CAST(20121119 AS CHAR(8)), 'YYYYMMDD'), 'MM/DD/YYYY')
FROM SYSIBM.SYSDUMMY1
This page might help you with the parsing in db2 you didn't know about. Format date to string
Edit: Oops, you said it was an integer. The cast() function will convert it to character and then you can use concat() and substr() to format it.
Using that function would be my approach.
Do the conversion in the display, using an existing global UDF.
This is the right way to handle this problem. Typically, formatting should not be applied to a data model (which is essentially what your query result is). Formatting should be applied when the data is displayed. This allows you to format the data differently when it is displayed in different contexts. Also, it improves code readability.
The drawback here, is that if the query is re-used, I need to duplicate the code necessary to convert the display value.
This is not a drawback. You will be formatting the data for presentation any time you are displaying data. Formatting a date is no different.
Calling a function that formats your data more than once is not "code duplication". You are simply using the formatting function as it was intended to be used.