I have one input field of type C.
PARAMETERS lv_sep TYPE c.
Field lv_sep should accept only special characters.
Can you help me how i can give this constraint?
you can do checks during AT-SELECTION-SCREEN. You could for instance check the parameter lv_sep for the characters you want to accept.
AT-SELECTION-SCREEN.
if not lv_sep CO '!"§$%&/()=?'.
message text-e01 type E.
endif.
Because I like to avoid NOT in IF statements when I can, I would propose this:
AT-SELECTION-SCREEN.
IF lv_sep CN '!"§$%&/()=?'.
MESSAGE text-e01 TYPE E.
ENDIF.
Related
My tableA has src_text field of type text. I want to be able to specify flags in my regexp in order to properly filter my text fields, like on this website.
select *
from tableA
where tableA.src_text ~ '/Par/gms'
This statement literally looks for '/Par/gms' string while I want it to filter by src_text fields with Par text inside it, using g, m and s regexp flags.
Thanks in advance for your time.
As GMB said, some flags like g only make sense if you are interested in the matching substrings, not if you want to test if the pattern matches or not.
You could use the function
regexp_match(string, pattern, flags)
which will return matching substrings. The result IS NOT NULL if the pattern matches.
I am using below code to do calculation
select column1 from tablename where code SIMILAR TO '%(-|_|–)EST[1-2][0-9](-|_)%'
for this column value -CSEST190-KCY18-04-01-L the condition was passed, but in actual I want to ignore this type of data.
The correct value which should pass through the above condition is
-CS-EST19-0-KCY18-04-01-L
-CS_EST19-0-KCY18-04-01-L
Any suggestions, how to avoid this type of confusion?
Easiest way is to go full-regex, instead of using SQL standard SIMILAR TO.
select column1 from tablename where code ~ '[_–-]EST[12][0-9][_-]'
Notice this is does not have to match the full string, and you don't have to add .* on both ends (equivalent of % in LIKE and SIMILAR TO). The reason you got a match on that is, because of the underscore _, which is a single wildcard character.
Also, I switched the order, in the square brackets, so that the dash is the last character. That way it's treated as a character literal, not as a range specifier.
I have to create a procedure with same parameters names as excel columns. Some loook like this 'xxx/xxx' or 'xxx - xxx'. Is there any work around to name parameteres in a stored procedure like this?
Forward slash (/) or dash (-) are not allowed in variable names
According to http://msdn.microsoft.com/en-us/library/ms175874.aspx, that means that the allowed characters are:
Letters as defined in the Unicode Standard 3.2. The Unicode
definition of letters includes Latin characters from a through z,
from A through Z, and also letter characters from other languages.
Decimal numbers from either Basic Latin or other national scripts.
The at sign (#), dollar sign ($), number sign (#), or underscore (_).
Okay first of all why would you ever want to use special characters? That is like saying I want to fry toast underwater with electricity, why can't I have an outlet to allow that? Special characters denote special things and as such many engines, not just in SQL, but most languages will not allow reserved characters for use in variables. The best you could do was put in parameters with the reversed '_' and then replace that AFTER the object was already created for echoing out. The placeholder name of '#(something)' is really arbitrary and could be #X or #LookAtMe. It's type is important to form a contract that must be fulfilled for execution but the naming is really for hooking up. Having said that if you just must have these weird names echoed out you could do something like this:
CREATE PROC pSimpleParam #My_Param INT
AS
SELECT #My_Param
GO
ALTER PROC pSimpleParam #My_Param INT
AS
SELECT
pr.name AS ParameterName
, REPLACE(pr.name, '_', '-') AS AlteredParameterName
FROM sys.procedures p
INNER JOIN sys.parameters pr ON pr.object_id = p.object_id
AND p.name = 'pSimpleParam'
GO
Referencing the page number variable in JasperReport as $V{PAGE_NUMBER}. Of course that works fine. However, I would like this report to have a page number preceded by a letter, as in:
A-1
A-2
...
A-N
Unfortunately, this does not appear to be permitted. Even when I get the expression editor to accept an expression, it still fails to compile. Always with "cannot cast from String to Integer", or "cannot cast from Integer to String" errors, or sometimes both.
"A-".concat($V{PAGE_NUMBER}.toString()) does not work. No possible variation works, mystifyingly.
Just a note, you can write it as "A-" + $V{PAGE_NUMBER}
Yeah, you can't teach smart. I neglected to change the field type from Integer to String. And I was about to disparage an awesome free product. D'Oh.
we are using oracle forms...
we have to protect (or) block a text item field from special charecters.
like ( !##$%^&*)
please send some guidences.... thanks in advance...
Regards,
Vijay
When your text box as some entered text you got to have a function that validates all input.
On that function you have a range off invalid values. That range is made in ASCII.
You can use format mask property like 999.99
Which version of forms?
Brute force method:
v_prohibited_chars VARCHAR2(100) := '!##$%^&*';
v_result VARCHAR2(4000);
...
-- strip prohibited characters
v_result := TRANSLATE(:form_field,'A'||v_prohibited_chars,'A');
-- if anything was stripped, lengths will differ
IF LENGTH(:form_field) <> LENGTH(v_result) THEN
error...
END IF
If I understand your comment correctly, you want to be able to filter the special character(s) out of the form field?
The above code does that, and places the result in v_result. So, if you have an input value of 'ABC#DEF#', and your filter mask is '!##$%^&*', then after executing TRANSLATE your result will be 'ABCDEF'. You can then reassign this value to your form field. If you just want to silently strip the character, you can skip the LENGTH checking and simply assign the output of TRANSLATE back to your form field:
:form_field := TRANSLATE(:form_field,'A'||v_prohibited_chars,'A');
What TRANSLATE does is check the characters in the first parameter against the characters in the second parameter. When it finds a match, it translates that character into the corresponding character in the third parameter. If no corresponding characters exist in the third parameter for one in the second, then the character is translated to NULL. If a character does not appear in the second parameter, it remains unchanged. So, the character 'A' is translated to 'A', and all of the other characters in the mask are translated to NULL. The third parameter cannot be NULL, hence the dummy translation of 'A' to 'A'.