I've got the following code in place with the idea being that I need a 30 character random number generated each time the stored procedure is called and the odd thing is that in most cases it works as intended but in other seemingly random cases it will only generate a 28 character random number.
'\\xxx-servername\folder\'+
CAST(CAST((RAND()*1000000000000000000000000000000) as decimal(30))as varchar(30)) +
RAM.AccountNumber+HRMRN.PrefixMedicalRecordNumber+'ESTIMATE N00001'+
REPLACE(CONVERT(VARCHAR(12),ISNULL(HRM.Birthdate,HRM.BirthdateComputed),111),'/','')+HRM.Sex+
REPLACE(CONVERT(VARCHAR(12),GetDate(),111),'/','')+LEFT(REPLACE(CONVERT(VARCHAR(12),GetDate(),108),':',''),4)+'.PDF' as [CPFileName]
Hope maybe someone can offer some advice because I'm at a loss...
I suspect that your system is automatically removing leading zeros. You can either re-insert those zeros yourself, or else construct your number using something like:
number <- ""
number.append(randomDigit(1,9))
repeat 29 times
number.append(randomDigit(0,9))
end repeat
That guarantees that you do not get a leading zero.
Related
I am using below code to sort. Everything works fine till E999. E1000 goes into hiding somewhere and is not part of sorting.
_order= 'employee_code desc'
Records are sorted based on string comparison. It compares first characters and if these are equal, second character is compared and so on.
In your case comparison works only to E999, because the next code has one character more than all previous codes.
When comparing E1000 with E999, the first code is smaller, because the second character of the first code is smaller.
The order of codes will be like this:
E098, E099, E100, E1000, E101, E102
In smaller scale you can see the same situation here:
x = ['E01', 'E02', 'E22', 'E99', 'E100', 'E10', 'E11']
x.sort()
print(x)
Output:
['E01', 'E02', 'E10', 'E100', 'E11', 'E22', 'E99']
So, to solve this issue you just need to increase the length of code (by adding 0 before the number if it is to short), so it always has the same length for all codes.
I am working on some legacy code at the moment and have come across the following:
FooString = String.Format("{0:####0.000000}", FooDouble)
My question is, is the format string here, ####0.000000 any different from simply 0.000000?
I'm trying to generalize the return type of the function that sets FooDouble and so checking to make sure I don't break existing functionality hence trying to work out what the # add to it here.
I've run a couple tests in a toy program and couldn't see how the result was any different but maybe there's something I'm missing?
From MSDN
The "#" custom format specifier serves as a digit-placeholder symbol.
If the value that is being formatted has a digit in the position where
the "#" symbol appears in the format string, that digit is copied to
the result string. Otherwise, nothing is stored in that position in
the result string.
Note that this specifier never displays a zero that
is not a significant digit, even if zero is the only digit in the
string. It will display zero only if it is a significant digit in the
number that is being displayed.
Because you use one 0 before decimal separator 0.0 - both formats should return same result.
In my mind this should be easy.. I have spent a good bit of time trying to get this right
Problem-
I have 1 data set that returns whole numbers as well as percents. What I am looking for is a formatting step to work and add the correct suffix (x100+% when % or nothing)
Here is what I have but don't get consistent results
=iif(Fields!Mid_Size.Value<1,Format(Fields!Mid_Size.Value,"P"),Format(Fields!Mid_Size.Value,"#"))
The raw data looks like:
Alpha Mid-Size
11 49
0.0718954248366013 0.320261437908497
Anyone have any ideas?
Try this:
=iif(Fields!Mid_Size.Value<1,FormatPercent(Fields!Mid_Size.Value,0),Format(Fields!Mid_Size.Value,"#"))
This uses the FormatPercent function. The '0' is for no decimal places; you can set that to however many you want.
I have some decimal numbers that I need to write to a text file with leading zeros when appropriate. I've done some research on this, and everything I've seen suggests something like:
REAL VALUE
INTEGER IVALUE
IF (VALUE.LT.0) THEN
IVALUE = CEILING(VALUE)
ELSE
IVALUE = FLOOR(VALUE)
ENDIF
WRITE(*,1) IVALUE, ABS(VALUE)-ABS(IVALUE)
1 FORMAT(I3.3,F5.4)
As I understand it, the IF block and ABS parts should allow this to work for all values on -100 < VALUE < 1000. If I set VALUE = 12.3456, the code above should produce "012.3456" as the output, and it does. However if I have something like VALUE = -12.3456, I'm getting "(3 asterisks).3456" as my output. I know the asterisks usually shows up when there are not enough characters provided for in the FORMAT statement, but 3 should be enough in this example (1 character for the "-" and two characters for "12"). I haven't tested this yet with something like VALUE = -9.876, but I'd expect the output to be "-09.8760".
Is there something wrong in my understanding of how this works? Or is there some other limitation of this technique that I'm violating?
UPDATE: Okay I've looked into this some more, and it seems to be a combination of a negative value and the I3.3 format. If VALUE is positive and I have the I3.3, it will put leading zeros as expected. If VALUE is negative and I only have I3 as my format, I get the correct value output, but it will be padded with spaces before the negative sign instead of padded with zeros after the negative (so -9.8765 is output as " -9.8765", but that leading space breaks what I'm using the .txt file for, so it's not acceptable).
Tho problem is with your integer data edit descriptor. With I3.3 you require at least 3 digits and the field width is only 3. There is no place for the minus sign. Use I4.3 or, In Fortran 95 and above, I0.3.
Answer to your edit: Use I0.3, it uses the minimum number of characters necessary.
But finally, you just probably want this: WRITE(*,'(f0.3)') VALUE
Of course, I could get what I'm looking for by changing it up a little bit to
REAL VALUE
INTEGER IVALUE
IF (VALUE.LT.0) THEN
WRITE(*,1) FLOOR(ABS(IVALUE)), ABS(VALUE)-FLOOR(ABS(VALUE))
1 FORMAT('-',I2.2,F5.4)
ELSE
WRITE(*,2) FLOOR(VALUE), ABS(VALUE)-FLOOR(BS(VALUE))
2 FORMAT(I3.3,F5.4)
ENDIF
But this feels a lot clunkier, and in reality I'm going to try to be writing multiple values in the same line, which will lead to really messy IF blocks or complex cursor movement, which I'd like to avoid if at all possible.
as another way to skin the cat.. I'd prefer not to do arithmatic on the data at all but just work on the format:
character*8 fstring/'(f000.4)'/
val=12.34
if(val.gt.1)then
write(fstring(3:5),'(i0)')6+floor(log10(val))
elseif(val.lt.-1)then
write(fstring(3:5),'(i0)')7+floor(log10(-val))
elseif(val.ge.0)
write(fstring(3:5),'(i0)')6
else
write(fstring(3:5),'(i0)')7
endif
write(*,fstring)val
just for fun with modern fortran that supports character functions you can roll that up in a function and end up with a construct like this:
write(*,'('//fstring(val1)//','//fstring(val2)//')')val1,val2
I have this insert command where iam trying to insert a number to be taken from loop
i=0
for line in column:
myStmt.executeQuery("INSERT INTO REVERSE_COL
( TABLE_NAME,COL_NAME,POS) values
(,'test','"+column[i]+"','"+i+"'")
i=i+1
POS IS NUMBER DATATYPE
but it works if i hard code as 1
i=0
for line in column:
myStmt.executeQuery("INSERT INTO REVERSE_COL
( TABLE_NAME,COL_NAME,POS) values
(,'test','"+column[i]+"',1")
I have tried only i , +i+ and other method but its not working any suggestion how to solve this .
Thanks everyone .
I have no jython experience, but I will still try to offer my personal approach and advice. Take from it what you will.
The first thing that I would look into, and perhaps this is something someone else knows offhand, is the way that a number is concatenated to the string. I'm speaking from a C++ background here, but a number i may well be converted to the ASCII character representing that value, and not necessarily the character that you intend.
For example, if i is 9, it may be placing a TAB into the string and not the number 9, which would be an ASCII value 57.
Again, I'm not telling you this IS the answer...but it's the first thing that pops into my mind. Good luck!