In a program I have used a function RPAD() to format data coming from DB2 db.
In one instance the value was Ãmber. The following function:
RPAD('Ãmber',10,' ')
gives 9 characters only.
The ASCII value of 'Ã' is 195. I am not able to understand the reason for this behaviour.
Could someone share their experience.
Thanks
By default, DB2 will consider the length of à to be 2, likely because it is counting bytes rather than characters.
values(LENGTH('Ãmber'))
6
You can override it for LENGTH and many other functions
values(LENGTH('Ãmber', CODEUNITS16))
5
Unfortunately, RPAD does not take a parameter like this. I'm guessing this might be because the function was added for Oracle compatibility rather than on its own merits.
You could write your own RPAD function as a stored procedure or UDF, or just handle it with a CASE statement if this is the only place where you need it.
Related
Is there any alternative for the FORMATMESSAGE() function in SQL?
Here is my scenario. I have a variable of VARCHAR(2000) which takes a string and which is getting formatted by FORMATMESSAGE(). Now the length of the variable is changed to VARCHAR(8000), here I cannot use the FORMATMESSAGE() because this function accepts 2047 characters. If the message contains 2,048 or more characters, only the first 2,044 are displayed.
I'm planning to create a function with similar logic, but curious to know if there is any alternative or any other function that does the similar functionality logic.
Note: I cannot split the variable into many and use it.
Beginner here.
Is there any other difference apart from syntax in position and strpos function?
If not then why do we have two functions which can achieve the same thing just with a bit of syntax difference?
Those functions do the exactly same thing and differ only in syntax. Documentation for strpos() says:
Location of specified substring (same as position(substring in string), but note the
reversed argument order)
Reason why they both exist and differ only in syntax is that POSITION(str1 IN str2) is defined by ANSI SQL standard. If PostgreSQL had only strpos() it wouldn't be able to run ANSI SQL queries and scripts.
You can use both commands in order to reach the same goal, i.e. finding the location of a substring in a given string. However, they have different syntaxes and order of arguments:
strpos(String, Substring);
position(Substring in String);
Take a look at all string functions and operators of PostgreSQL here
I'm converting a rather large old fix-format code written in Fortran 77 to free-format. Within the code I frequently encounter read statements like
DOUBLE PRECISION :: VARIABLE
read(1,10) VARIABLE
10 format(2A10)
However, what it reads from input file is in fact a line of string. The code runs perfectly fine, but it crashes when one tries to read VARIABLE from a namelist instead of a fixed format input file.
How is this possible in Fortran? Is there any reference where I can find more information about?
Any help is greatly appreciated.
This comes from the days before F77 when doubles and integers were used for storing characters. From the format statement, this is probably from a CDC which could store 10 six bit characters in each word. Double precision was two words so it was two lots of 10 characters. If you change the code to
CHARACTER(LEN=20) VARIABLE
READ(1,10) VARIABLE
10 FORMAT(A20)
It should work. There isn't a lot of information about on CDC compilers. I've never tried using a namelist with one so I can't really comment about it. Try http://bitsavers.trailing-edge.com/pdf/cdc/cyber/cyber_70/chippewa/Chippewa_Fortran-Run_Apr66.pdf
how can i know what is the format code of parameter that comes to my page?
whorking with ASP
some of the character that i see cant found in the DB (access)
i want to know the unicode of the value
Assuming you're using C#, you can get the 16-bit characters of strings as integers using (int) foo[0].
(In VB.NET, I think it would be Convert.ToInt32(foo.Chars(0)). In VBA, Asc(foo).)
If the string you're passing to ADO is correct, but the results are not as expected, either the data in the database was already corrupted by some earlier non-Unicode-friendly process, or else Access is not treating the input string and the database record as equal for some unexpected reason. (Equivalence of Unicode strings is a bit complicated.)
I am writing a function that transliterates UNICODE digits into ASCII digits, and I am a bit stumped on what to do if the string contains digits from different sets of UNICODE digits. So for example, if I have the string "\x{2463}\x{24F6}" ("④⓶"). Should my function
return 42?
croak that the string contains mixed sets?
carp that the string contains mixed sets and return 42?
give the user an additional argument to specify one of the three above behaviours?
do something else?
Your current function appears to do #1.
I suggest that you should also write another function to do #4, but only when the requirement appears, and not before .
I'm sure Joel wrote about "premature implementation" in a blog article sometime recently, but I can't find it.
I'm not sure I see a problem.
You support numeric conversion from a range of scripts, which is to say, you are aware of the Unicode codepoints for their numeric characters.
If you find an unknown codepoint in your input data, it is an error.
It is up to you what you do in the event of an error; you may insert a space or underscore, or you may abort conversion. What you would do will depend on the environment in which your function executes; it is not something we can tell you.
My initial thought was #4; strictly based on the fact that I like options. However, I changed my mind, when I viewed your function.
The purpose of the function seems to be, simply, to get the resulting digits 0..9. Users may find it useful to send in mixed sets (a feature :) . I'll use it.
If you ever have to handle input in bases greater than 10, you may end up having to treat many variants on the first 6 letters of the Latin alphabet ('ABCDEF') as digits in all their forms.