I do struggle with some of these conversions, so I do apologize, I have asked a similar question in the past, but just can't get my head around how to achieve this.
So a value of 50.00 is currently being exported into the following format -
000000000000050000
A value of 25.99 would look like
000000000000025990
This is a 18 character field where any leading characters are padded with a zero.
What I am trying to do is convert that to a 19 character string - still with leading zeros - but the value of 50 or 25.99 is slightly different -
000000000000050000 becomes 0000000000000005000
000000000000025990 becomes 0000000000000002599
Any help would be greatly appreciated.
You would appear to want:
select '00' + left(str, 17)
This is a very strange format. Perhaps you should consider using numeric/decimal, which can accurately represent the number.
A lot of assumptions go into this answer, but...
SELECT '00'+LEFT(OriginalField, 17)
That would truncate your original 18th character and simply put two more zero's on the front.
The solution is not so simple if you need to potentially round up the 17th character.
Related
We have one column in sql server where we need to consider the all the digits as it is transaction table.The column data type like decimal(38,35) ,its appending zeroes when in sql server like the value is 1.2369 but its displaying as 1.236900000000000000.. but it can be restricted by using float and cast like
"select cast(cast('1.2369'as decimal(38,35))as float)" it will truncate all the zeroes but the real question is when we use the same expression for the bigger decimal value like 1.236597879646479444896645 its truncate the trailing values,considering only up-to scale of 15 digits,if anybody finds the logic for this one please help me .Thank you and
Note :The values are always dynamic.
Becouse float has a precision of 15 digits.
See documentation: float and real
To format a DECIMAL(38,35) without insignificant zeroes, use an explicit FORMAT string, e.g.
SELECT FORMAT(1.23690000000000000, '0.' + REPLICATE('#', 35))
gives 1.2369 (SQL Server 2012 and up). Note, however, that the resulting type is a string, not a number, and so this should only ever be done as the final step (and only if your client software isn't smart enough to format the values on its own). While you're calculating with it, there is either no need to cut off digits, or else you need to be explicit about it by converting to the appropriate DECIMAL (e.g. 1.2369 fits in a DECIMAL(5, 4)). SQL Server can't do this automatically because it doesn't know what kind of precision you're going for in your calculations, but it is definitely something you must take into account, because combining DECIMALs of different scale and precisions can give unexpected results when you're close to the edge.
If you want to remove trailing 0s, recognize that this is now string formatting, not any numeric processing. So we'll convert it to a string and then trick RTRIM into doing the job for us:
select REPLACE(
RTRIM(
REPLACE(
CONVERT(varchar(40),convert(decimal(38,35),'1.2069'))
,'0',' '))
,' ','0')
As I said in a comment though, it's usually more appropriate to put these presentation concerns in your presentation layer, rather than doing it down in the database - especially if whatever is consuming this result set wants to work with this data numerically. In that case, leave it alone - the trailing zeroes are only their because that's how management studio chooses to format decimals for display.
I am in the process of outputting some results I get from some arrays in C in a nice table format, but I want to cut the value down to 2 digits past the decimal point.
Part of my table code looks something like this (some fake arguments just to get the point across).
printf("%15d %15f %15f\n", arr[i], arr2[i], arr3[i])
I want to trim some of my double variables down so a 55.583159 will just return 55.58 without having to get rid of the double data type. So essentially I'm looking for a way to keep "%15f" and also add into it a "%.2f" in a nice clean manor.
Any suggestions?
you can combine the output format, so if you want 15 digit width (%15f) and 2 places after the decimal (%.2f) you can use (%15.2f)
printf("%15d %15.2f %15.2f\n", arr[i], arr2[i], arr3[i])
this explains different formatting well
I have a SQL Server database that has a table that contains a field of type varbinary(256).
When I view this binary field via a query in MMS, the value looks like this:
0x004BC878B0CB9A4F86D0F52C9DEB689401000000D4D68D98C8975425264979CFB92D146582C38D74597B495F87FEA09B68A8440A
When I view this same field (and same record) using CFDUMP, the value looks like this:
075-56120-80-53-10279-122-48-1144-99-21104-1081000-44-42-115-104-56-10584373873121-49-714520101-126-61-115116891237395-121-2-96-101104-886810
(For the example below, the original binary value will be #A, and the CFDUMP value above will be #B)
I have tried using CAST(#B as varbinary(256)) but didn't get the same value as #A.
What must I do to convert the value retrieved from CFDUMP into the correct binary representation?
Note: I no longer have the applicable records in the database. I need to convert #B into the correct value that can re-INSERT into a varbinary(256) field.
(Expanded from comments)
I do not mean this sarcastically, but what difference does it make how they display binary? It is simply a difference in how the data is presented. It does not mean the actual binary values differ.
It is similar to how dates are handled. Internally, they are a big numbers. But since most people do not know which date 1234567890 represents, applications chose to display the number in a more human friendly format. So SSMS might present the date as 2009-02-13 23:31:30.000, while CF might present it as {ts '2009-02-13 23:31:30'}. Even though the presentations differ, it still the same value internally.
As far as binary goes, SSMS displays it as hexadecimal. If you use binaryEncode() on your query column, and convert the binary to hex, you can see it is the same value. Just without the leading 0x:
writeDump( binaryEncode(yourQuery.binaryColumn, "hex") )
If you are having some other issue with binary, could you please elaborate?
Update:
Unfortunately, I do not think you can easily convert the cfdump representation back into binary. Unlike Railo's implementation, Adobe's cfdump just concatenates the numeric representation of the individual bytes into one big string, with no delimiter. (The dashes are simply negative numbers). You can reproduce this by looping through the bytes of your sample string. The code below produces the same string of numbers you posted.
bytes = binaryDecode("004BC878B0CB9A4F...", "hex");
for (i=1; i<=arrayLen(bytes); i++) {
WriteOutput( bytes[i] );
}
I suppose it is theoretically possible to convert that string into binary, but it would be very difficult. AFAIK, there is no way to accurately determine where one number (or byte) begins and the other ends. There are some clues, but ultimately it would come down to guesswork.
Railo's implementation, displays the byte values separated by a dash "-". Two consecutive dashes indicates a negative number. ie "0", "75", "-56", ...
0-75--56-120--80--53--102-79--122--48--11-44--99--21-104--108-1-0-0-0--44--42--115--104--56--105-84-37-38-73-121--49--71-45-20-101--126--61--115-116-89-123-73-95--121--2--96--101-104--88-68-10
So you could probably parse that string back into an array of bytes. Then insert the binary into your database using <cfqueryparam cfsqltype="CF_SQL_BINARY" ..>. Unfortunately that does not help you, but the explanation might help the next guy.
At this point, I think your best bet is to just restore the data from a database backup.
I'm trying to use this expression to round money type to two decimal point.
=Format(Fields!ClosingBalance.Value,"#,##0.##")
The problem is I'm getting comma(,) in between, comma I do not want.
Also, 100.00 is showing 100. Here I want 100.00.
Please help
Try changing the format string to #.0,00. That will give you two fixed decimal digits. Your 'comma' is in the language settings. You can create your own culture though and assign it to the renderer.
If you don't want a comma, don't place one in the format string:
=Format(Fields!ClosingBalance.Value,"#.##")
If you want 100.00 instead of 100 the correct Format() is
=Format(Fields!ClosingBalance.Value,"0.00")
In format strings # means show character if non-zero and 0 means show character, zero included
I'm currently messing around in FORTRAN 77 and I've ran into a problem that I can't seem to figure out. I'm trying to read from a file that looks similar to below:
000120 Description(s) here 18 7 10.15
000176 Description(s) here 65 20 56.95
...
The last column in each row is a monetary amount (never greater than 100). I am trying to read the file by using code similar to below
integer pid, qty, min_qty
real price
character*40 descrip
open(unit=2, file='inventory.dat', status='old')
read(2, 100, IOSTAT=iend) pid, descript, qty, min_qty, price
100 format(I11, A25, I7, I6, F5)
Everything seems to be read just fine, except for the last column. When I check the value of price, say for example, for the second line; instead of getting 56.95 I get something like 56.8999999999.
Now, I understand that I might have trailing 9's or whatnot because it's not totally precise, but shouldn't it be a little closer to 95 cents? Maybe there's something that I'm doing wrong, I'm not sure. Hopefully I'm just not stuck with my program running like this! Any help is greatly appreciated!
Is that exactly the code you use to read the file? Do you have "X" formats to align the columns? Such as (I11, A25, 2X, I7, 3X, I6, 3X, F5) (with made up values). If you got the alignment off by one and read only "56.9" for "56.95", then floating point imprecision could easily give you 56.89999, which is very close to 56.9
You could also read the line into a string and read the numbers from sub-strings -- this would require only precisely identifying the location of the string. Once the sub-strings contained only spaces and numbers, you could use a less-finicky IO directed read: read (string (30:80), *) qty, min_qty, price.