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'.
Related
So I have a dataset which I want to export to csv with pipe as separator and no escape character.
That dataset contains in fact 4 source columns, 3 regular ones (just text) and one variable one.
That last column holds another subset of values that are also separated with a pipe.
Purpose is that the export looks like this, where the values are coming from my 4th field.
COL1|COL2|COL3|VAL1|VAL2|VAL3|....
The number of values can be different for each record but.
When I set the csv export separator to ";", I get this result which is expected
COL1;COL2;COL3;VAL1|VAL2|VAL3|....
However setting it to "|", it throws the error DF-CSVWriter-InvalidEscapeSetting.
Most likely because it detected the separator character in my 4th field and then enforces that an escape character needs to be set.
Which is a logical thing in most case but in my case I would like him to ignore this and just export as-is.
Any way how I can work around this, perhaps with a different approach or some additional settings?
Split & flatten produces extra rows but that's not what I want.
Regards,
Sven Peeters
As you have the same characters in the column value same as your delimiter character, with no escape character in your dataset will throw an error.
You have to change the delimiter character to a different character or add a Quote character and Escape character to Double quote(").
Downloaded file:
I'm trying to change the value of nulls to something else that can be used to filter. This data comes from a QVD file. The field that contains nulls, contains nulls due to no action taken on those items ( they will eventually change to something else once an action has been taken). I found this link which was very informative but i tried multiple solutions from the document to no avail.
What i don't quite understand is that whenever i make a new field (in the script or as an expression) the formula does not propagate in the records that are null, it shows " - ". For instance, the expression isNull(ActionTaken) will return false in a field that that not null, but only " - " in fields that are null. If i export the table to Excel, the " - " is exported, i copy this cell to a text analyzer i the UTF-8 encoded is \x2D\x0A\x0A, i'm not sure if that's an artifact of the export process.
I also tried using the NullAsValue statement but no luck. Using a combination of Len & Trim = 0 will return the same result as above. This is only one table, no other tables are involved.
Thanks in advance.
I had a similar case few years ago where the field looked empty but actually it was filled with a character which just looked empty. Trimming the field also didnt worked as expected in this case, because the character code was different
What I can suggest you is to check if the character number, returned for the empty value, is actually an empty string. You can use the ord to check the character number for the empty values. Once you have the number then you can use this number to replace it with whatever you want (for example empty string)
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
I am trying to read values from form using ReadParse() function in Hash (%in), I am not getting elements as order I submit in form, I Want get in same oreder as I submit in form,
please give me solution. Thanks.
Check perldoc CGI FETCHING THE NAMES OF ALL THE PARAMETERS PASSED TO YOUR SCRIPT:
my #names = $query->param;
As of version 1.5, the array of parameter names returned will be in the same order as they were submitted by the browser. Usually this order is the same as the order in which the parameters are defined in the form (however, this isn't part of the spec, and so isn't guaranteed).
Hash keys/values are not stored in the order they are added.
What are you trying to accomplish? Perhaps there is another way?
I didn't realize that the order is specified in the HTML spec:
application/x-www-form-urlencoded
This is the default content type. Forms submitted with this content
type must be encoded as follows:
Control names and values are escaped. Space characters are replaced by
'+', and then reserved characters are escaped as described in
[RFC1738], section 2.2: Non-alphanumeric characters are replaced by
'%HH', a percent sign and two hexadecimal digits representing the
ASCII code of the character. Line breaks are represented as "CR LF"
pairs (i.e., '%0D%0A').
The control names/values are listed in the
order they appear in the document. The name is separated from the
value by '=' and name/value pairs are separated from each other by
'&'.
[http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4]