ORA-12728: invalid range in regular expression - sql

I want to check if valid phone number is inserting in table, so my trigger code is here:
select start_index
into mob_index
from gmarg_mobile_operators
where START_INDEX = substr(:new.contact_info,0,3);
if (REGEXP_LIKE (:NEW.CONTACT_INFO,'^(?:'|| mob_index ||')[\-,\:]{0,1}[0-9][0-9][\-,\:]{0,1}[0-9][0-9][\-,\:]{0,1}[0-9][0-9]')) then
found := 1;
end if;
I've checked my regex: "^(?:555)[-,:]{0,1}[0-9][0-9][-,:]{0,1}[0-9][0-9][-,:]{0,1}[0-9][0-9]" on several online tools and it is correct.
When I run my trigger, it compiles successfully, but during inserting a row following error is shown:
insert into GMARG_CONTACTS
(CLINET_ID,CONTACT_INFO,contact_type_id)
values
(0,'555194117','Mobile')
Error report -
SQL Error: ORA-12728: invalid range in regular expression
ORA-06512: at "HR.GMARG_TRIGGER_CONTACT", line 12
ORA-04088: error during execution of trigger 'HR.GMARG_TRIGGER_CONTACT'
12728. 00000 - "invalid range in regular expression"
*Cause: An invalid range was found in the regular expression.
*Action: Ensure a valid range is being used.
So, if my regex is correct, why does oracle shows error?
I tried to find answer, or redifine my regex, but no forward steps...
thank you in advance

Regexp don't use \ to protect - in a bracket expression. You only have to put - as the first character, just after the opening bracket:
IF REGEXP_LIKE('--,,::', '[\-,:]*')
...
=> ORA-12728: invalid range in regular expression
If you're curious, when encountering [\-,:] Oracle understand: "any character in the range from \ to , or the character :". The reason why this raises an exception is \ appears to be after , according to their ASCII value. And Oracle don't accept range having a starting value after the ending one.
On the other hand:
IF REGEXP_LIKE('--,,::', '[-,:]*')
Works as expected.
As a side note, [-,:]{0,1} meaning "zero or one occurrence of - or , or :" could be written [-,:]?.

Related

Replace string output from query in results tab

I have a DB with a large number of CLOB columns. Each of these columns contains a repeated set of characters, which are fillers designed to designate a paragraph break (I didn't design the tables).
Is there a way to write the script so that each time the script finds these characters it enters a paragraph or line break into the results that are returned, while still saying in the same row of the results?
The data would look like
"Hello all,XYZ!£$I can't get ... to work.XYZ!£$The error meassge says ..."
As an example:
SELECT *
FROM ALERTS
REPLACE(Alert_Text, 'XYZ!£$', CH(13))
(Obviously the above returns errors)
The ideal output of the query would be:
"Hello all,
I can't get ... to work.
The error meassge says ..."
I am using SqlDbx to connect to an Oracle DB.
The obvious error is ORA-00904: "CH": invalid identifier
The reason is, that the function name is CHR
select REPLACE(txt, 'XYZ!£$', CHR(13)) from tab;
REPLACE(TXT,'XYZ!£$',CHR(13))
--------------------------------------------------------------------------------
Hello all,
I can't get ... to work.
The error meassge says ...

sql code not working in oraclesqldeveloper: Invalid Character error

I wrote a code to find few items by a particular number but it keeps saying that is something is an "invalid character"."ORA-00911: invalid character
00000 - "invalid character"
*Cause: identifiers may not start with any ASCII character other than
letters and numbers. $#_ are also allowed after the first
character. Identifiers enclosed by doublequotes may contain
any character other than a doublequote. Alternative quotes
(q'#...#') cannot use spaces, tabs, or carriage returns as
delimiters. For all other contexts, consult the SQL Language
Reference Manual.
*Action: Error at Line: 14 Column: 23"
My brain is blown,I am not sure where the problem exists.
Need Help. Thanks.
select
a.app_num,
a.crs_pol_num,
kl.score,
kl.risk_level_desc
from
application a,
kyc_new_risk_level kl
where
a.app_num = kl.app_num
and a.app_num = (select max(to_number(a1.app_num)) from
application a1,
kyc_new_risk_level kl1 where kl1.app_num = a1.app_num and a1.crs_pol_num = a.crs_pol_num)
and a.crs_pol_num in (‘CG0147511’,
‘CG0133662’,
‘CG0138107’,
‘493186’,
‘CG0142230’,
‘CS0138382’,
‘CG0147509’,
‘CG0147545’,
‘921141048001’,
‘CG0347239’,
‘CG0142212’,
‘CG0147518’,
‘CG0134057’,
‘CG0143158’,
‘CG0147536’,
‘CG0244124’,
‘CG0134102’,
‘CG0241709’,
‘CG0147197’,
‘CG0137204’,
‘CG0347496’,
‘CG0147490’,
‘CG0143467’,
‘CG0135689’,
‘CG0146904’,
‘CS0132517’,
‘CG0145455’,
‘CG0147554’,
‘CG0133626’,
‘CG0147560’,
‘CG0135359’,
‘CG0133303’,
‘921165287001’,
‘CG0147546’,
‘CG0114581,
‘CG0122266’,
‘CG0236577’,
‘CG0345349’,
‘CG0132670’,
‘CG0147413’,
‘CG0241646’,
‘CG0143783’,
‘CG0245160’,
‘CG0124066’,
‘CG0124830’,
‘CG0145956’,
‘CG0232953’,
‘CG0144479’,
‘CG0147569’,
‘CG0147555’,
‘CG0244857’,
‘CG0147562’,
‘CG0347578’,
‘CG0346461’,
‘CS0133352’,
‘512097’,
‘CS0127026’,
‘CG0147583’,
‘CG0233314’,
‘CG0247096’,
‘CG0131282’,
‘CG0123462’,
‘CS0124502’,
‘CG0146034’,
‘CG0140236’,
‘CS0126420’,
‘CG0147557’,
‘CG0123182’,
‘CG0233300’,
‘CG0132782’,
‘CG0147501’,
‘CS0141693’,
‘CG0145237’,
‘CG0141763’,
‘CG0147591’,
‘CG0144107’,
‘CG0125208’,
‘CG0132306’);
SQL Developer is showing you the problem before you even run your query
That's not a quote, it's a smart quote. Which is nice for browsers and word processors - but not so much for the database engine.
If you click on that hint, it will replace it with a real single quote.
But with so many to fix, would be much faster, better to use search and replace.
But your cursor on the bad character, and hit Ctrl+R
And then hit 'replace all', then repeat for the closing smart quote.
But in case you missed all that, the error also back from the DB tells you where the issue is

Hive -character '<EOF>' not supported here

Select * from mytable where field=
'ce7bd3d4-dbdd-407e-a3c3-ce093a65abc9;cdb597073;7cf6cda5fc'
Getting Below Error while running above query in Hive
FAILED: ParseException line 1:92 character '' not supported here
<EOF> here means End Of File. When you get an "unexpected End Of File" error it means the parser reached the end of the query unexpectedly. This typically happens when the parser is expecting to find a closing character, such as when you have started a string with ' or " but have not closed the string (with the closing ' or ").
When you come across these types of errors it is good to check that your query can be parsed correctly. In addition, the error gives you the location where the parser failed: line 1:92 in this case. You can usually look at this location (character 92 of the query) and work backwards to find the problem character.
Try adding the database name to the "from" statement as below.
Select * from my_db_name.mytable where field= 'ce7bd3d4-dbdd-407e-a3c3-
ce093a65abc9;cdb597073;7cf6cda5fc';
Hive uses the default database when no database was previously specified.

PostgreSQL RETURNING fails with REGEXP_REPLACE

I'm running PostgreSQL 9.4 and are inserting a lot of records into my database. I use the RETURNING clause for further use after an insert.
When I simply run:
... RETURNING my_car, brand, color, contact
everything works, but if I try to use REGEXP_REPLACE it fails:
... RETURNing my_car, brand, color, REGEXP_REPLACE(contact, '^(\+?|00)', '') AS contact
it fails with:
ERROR: invalid regular expression: quantifier operand invalid
If I simply run the query directly in PostgreSQL it does work and return a nice output.
Tried to reproduce and failed:
t=# create table s1(t text);
CREATE TABLE
t=# insert into s1 values ('+4422848566') returning REGEXP_REPLACE(t, '^(\+?|00)', '');
regexp_replace
----------------
4422848566
(1 row)
INSERT 0 1
So elaborated #pozs suggested reason:
set standard_conforming_strings to off;
leads to
WARNING: nonstandard use of escape in a string literal
LINE 1: ...alues ('+4422848566') returning REGEXP_REPLACE(t, '^(\+?|00)...
^
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
ERROR: invalid regular expression: quantifier operand invalid
update
As OP author says standard_conforming_strings is on as supposed from 9.1 by default working with psql and is off working with pg-prommise
update from vitaly-t
The issue is simply with the JavaScript literal escaping, not with the
flag.
He elaborates further in his answer
The current value of environment variable standard_conforming_strings is inconsequential here. You can see it if you prefix your query with SET standard_conforming_strings = true;, which will change nothing.
Passing in a regEx string unescaped from the client is the same as using E prefix from the command line: E'^(\+?|00)'.
In JavaScript \ is treated as a special symbol, and you simply always have to provide \\ to indicate the symbol, which is what needed for your regular expressions.
Other than that, pg-promise will escape everything correctly, here's an example:
db.any("INSERT INTO users(name) VALUES('hello') RETURNING REGEXP_REPLACE(name, $1, $2)", ['^(\\+?|00)', 'replaced'])
To understand how the command-line works, prefix the regex string with E:
db.any("INSERT INTO users(name) VALUES('hello') RETURNING REGEXP_REPLACE(name, E$1, $2)", ['^(\\+?|00)', 'replaced'])
And you will get the same error: invalid regular expression: quantifier operand invalid.

Removing replacement character � from column

Based on my research so far this character indicates bad encoding between the database and front end. Unfortunately, I don't have any control over either of those. I'm using Teradata Studio.
How can I filter this character out? I'm trying to perform a REGEX_SUBSTR function on a column that occasionally contains �, which throws the error "The string contains an untranslatable character".
Here is my SQL. AIRCFT_POSITN_ID is the column that contains the replacement character.
SELECT DISTINCT AIRCFT_POSITN_ID,
REGEXP_SUBSTR(AIRCFT_POSITN_ID, '[0-9]+') AS AUTOROW
FROM PROD_MAE_MNTNC_VW.FMR_DISCRPNCY_DFRL
WHERE DFRL_CREATE_TMS > CURRENT_DATE -25
Your diagnostic is correct, so first of all, you might want to check the Session Character Set (it is part of the connection definition).
If it is ASCII change it to UTF8 and you will be able to see the original characters instead of the substitute character.
And in case the character is indeed part of the data and not just an indication for encoding translations issues:
The substitute character AKA SUB (DEC: 26 HEX: 1A) is quite unique in Teradata.
you cannot use it directly -
select '�';
-- [6706] The string contains an untranslatable character.
select '1A'XC;
-- [6706] The string contains an untranslatable character.
If you are using version 14.0 or above you can generate it with the CHR function:
select chr(26);
If you're below version 14.0 you can generate it like this:
select translate (_unicode '05D0'XC using unicode_to_latin with error);
Once you have generated the character you can now use it with REPLACE or OTRANSLATE
create multiset table t (i int,txt varchar(100) character set latin) unique primary index (i);
insert into t (i,txt) values (1,translate ('Hello שלום world עולם' using unicode_to_latin with error));
select * from t;
-- Hello ���� world ����
select otranslate (txt,chr(26),'') from t;
-- Hello world
select otranslate (txt,translate (_unicode '05D0'XC using unicode_to_latin with error),'') from t;
-- Hello world
BTW, there are 2 versions for OTRANSLATE and OREPLACE:
The functions under syslib works with LATIN.
the functions under TD_SYSFNLIB works with UNICODE.
In addition to Dudu's excellent answer above, I wanted to add the following now that I've encountered the issue again and had more time to experiment. The following SELECT command produced an untranslatable character:
SELECT IDENTIFY FROM PROD_MAE_MNTNC_VW.SCHD_MNTNC;
IDENTIFY
24FEB1747659193DC330A163DCL�ORD
Trying to perform a REGEXP_REPLACE or OREPLACE directly on this character produces an error:
Failed [6706 : HY000] The string contains an untranslatable character.
I changed the CHARSET property in my Teradata connection from UTF8 to ASCII and I could now see the offending character, looks like a tab
IDENTIFY
Using the TRANSLATE_CHK command using this specific conversion succeeds and identifies the position of the offending character (Note that this does not work using the UTF8 charset):
TRANSLATE_CHK(IDENTIFY USING KANJI1_SBC_TO_UNICODE) AS BADCHAR
BADCHAR
28
Now this character can be dealt with using some CASE statements to remove the bad character and retain the remainder of the string:
CASE WHEN TRANSLATE_CHK(IDENTIFY USING KANJI1_SBC_TO_UNICODE) = 0 THEN IDENTIFY
ELSE SUBSTR(IDENTIFY, 1, TRANSLATE_CHK(IDENTIFY USING KANJI1_SBC_TO_UNICODE)-1)
END AS IDENTIFY
Hopes this helps someone out.