I have column phone number with value and want to update the table column such that country code doesnt exist.
19083452345
14084456789
12023458900
18163456789
I tried to use LPAD, LTRIM but couldnt succeed.
Something like this using SUBSTR:
update tablename set phone=substr(phone,2,length(phone)-1)
Use regular expressions (regex). Before doing it, check for the way country code are being written in your database, what standard is being used, if any (E.164 is tendency, but not always followed). For example, a mobile phone number in UK may be registered as '07911 123456' or also '+44 7911 123456' (and with or without blanks). There is a great deal of regular expressions in pages such as http://regexlib.com/Search.aspx?k=phone+number&c=0&m=0&ps=20&p=11&AspxAutoDetectCookieSupport=1
I don't know what flavor of Db2 are you using (Db2 for IBM i, Db2 for zOS, or Db2 for LUW) and it may have small variations on the regex support among them. The following article explain how to use regex in Db2 11.1 for LUW: https://www.idug.org/p/bl/et/blogaid=605
Related
I need to search an oracle table column for multiple word strings in cognos oracle query.
For example:
If Focus parameter returns multiple values as below
TRAINING
OMNIA
COUNTER
PROGRAM
And I need to search project.proj_name column like '%TRAINING%' or '%OMNIA%' or '%COUNTER%' or '%PROGRAM%'
I am trying below but I know it does only single value match not multiple. I want to know how to achieve multiple value match here.
'-99' in (#promptmany('Focus', 'string','-99')#) OR REGEXP_LIKE(proj_name, #promptmany('Focus', 'string','-99')#))
Working from Cognos Paul's solution to use output from promptmany as a table:
Assuming your query is named Q1...
Add a query. (Q2)
Add a SQL object to that query.
Set the Data source property for the SQL object.
Change the SQL Syntax property to IBM Cognos.
Define the query as
SELECT
parameterValue
FROM (VALUES
(#join('),(',split(',',promptmany('Scenarios','string',sq('N/A'))))#)
) query(parameterValue)
(change the names for your own use case)
Add a query. (Q3)
Add a join to the new query.
Add Q1 and Q2 to the empty boxes for the join leading to Q3.
Set the join as
[Q1].[proj_name] like '%' || [Q2].[parameterValue] || '%'
Add the required data items to Q3.
Since two keywords (from your parameter -> Q2) could be found in a single value (in Q1), you'll likely end up with duplicate rows. Cognos will probably handle this with its default aggregations, but keep a lookout.
Be careful with this. The new query (Q2) will probably be joined on the Cognos server, not on the database server. Be sure you have sufficient filters leading into this structure so Cognos is not trying to process your entire database.
This worked for me with SQL Server. I don't have an Oracle database to test against, but using IBM Cognos as the SQL Syntax should handle that.
To use REGEXP_LIKE to solve this problem, you'll need to get the second argument correct. I can't see any reason to see the error message ORA-00996: the concatenate operator is ||, not |, but I'm not working with your code in your system.
You don't specify which version of Cognos, or even which Cognos product, you are using. I'll assume Cognos Analytics 11.1.7.
To determine what Cognos Analytics is doing with your macro, create a very simple query with one item from the database (preferably from a very small table) and another data item that contains the macro. So the data item expression is:
#sq(join('|',split(',',promptmany('Focus','string','-99'))))#
When you run this, you may not be prompted. You'll see the value is -99. So to test this we'll need to remove the default so that the prompt becomes required.
#sq(join('|',split(',',promptmany('Focus','string'))))#
Be sure to enter more than one value when you test.
In my environment, the parameter returns a value that is my values surrounded by quotes (') and delimited by semicolons (;). So my tests produced the following:
expression
value
#sq(promptmany('Focus','string'))#
'PROGRAM';'COUNTER';'TRAINING'
#sq(join('|',split(',',promptmany('Focus','string'))))#
'PROGRAM';'COUNTER';'TRAINING'
#sq(join('|',split(';',promptmany('Focus','string'))))#
'PROGRAM'|'COUNTER'|'TRAINING'
replace(#sq(join('|',split(';',promptmany('Focus','string'))))#, '''', '')
PROGRAM|COUNTER|TRAINING
Your mileage may vary.
At this point, you know which macro to use in the REGEXP_LIKE function.
In one scenario we are dynamically creating sql to create temp tables on-fly. There is no issue with table_name as it is decided by us however the column-names are provided by sources not in our control.
Usually we would check the column names using below query:
select ..
where NOT REGEXP_LIKE (Column_Name_String,'^([a-zA-Z])[a-zA-Z0-9_]*$')
OR Column_Name_String is NULL
OR Length(Column_Name_String) > 30
However is there any build in function which can do a more extensive check. Also any input on the above query is welcome as well.
Thanks in advance.
Final query based on below answers:
select ..
where NOT REGEXP_LIKE (Column_Name_String,'^([a-zA-Z])[a-zA-Z0-9_]{0,29}$')
OR Column_Name_String is NULL
OR Upper(Column_Name_String) in (select Upper(RESERVED_WORDS.Keyword) from V$RESERVED_WORDS RESERVED_WORDS)
Particularly not happy with character's like $ in column name either hence won't be using..
dbms_assert.simple_sql_name('VALID_NAME')
Instead with regexp I can decide my own set of character's to allow.
This answer does not necessarily offer either a performance or logical improvement, but you can actually validate the column names using a single regex:
SELECT ...
WHERE NOT
REGEXP_LIKE (COALESCE(Column_Name_String, ''), '^([a-zA-Z])[a-zA-Z0-9_]{0,29}$')
This works because:
It uses the same pattern to match columns, i.e. starting with a letter and afterwards using only alphanumeric characters and underscore
NULL column names are mapped to empty string, which fails the regex
We use a length quantifier {0,29} to check the column length directly in the regex
" is there any build in function which can do a more extensive check."
Oracle has the DBMS_ASSERT.SIMPLE_SQL_NAME() function. This returns the passed name if it meets the Oracle naming rules ...
select dbms_assert.simple_sql_name('VALID_NAME') from dual;
... and hurls ORA-44003 if the name is invalid.
Valid names permit any characters if the name is double-quoted (yuck, but then so is creating "temp tables on-fly"). Also the function doesn't check the length of the name, so you will still need to validate that yourself.
Find out more in the docs.
Also here is a SQL Fiddle.
"creating a table with comment column is not possible as its a invalid identifier"
Fair point. DBMS_ASSERT is primarily aimed at preventing SQL injection. So it verifies that a value conforms to Oracle's naming rules, not that the value is a valid Oracle name. To catch things like comment you will also need to check the value against V$RESERVED_WORDS, probably where reserved != 'Y'. As this is a V$ view select on it is not granted by default; if you don't have access you'll need to ask your friendly DBA to help out.
" For validating column names I believe I should check with the entire list"
Up to you. The distinction is that some keywords can legitimately be used as identifiers. For instance TYPE only became a reserved word in Oracle version 8 when they introduced the object-relational stuff. But there were a lot of tables and views in existing systems which used 'TYPE' as a column name (not least the Oracle data dictionary). If Oracle had made TYPE a properly reserved word it would have broken all those systems. So the list of reserved words which cannot be used as identifiers is a sub-set of all the Oracle keywords.
Opinions on the general task:
"we are getting data from external sources (files) and the job of the program/script is to push that data to oracle tables."
There are two parts to this task.
The first is that you should have agreed a standard format for these files with the third parties. There should be no need for discovery of the files' structure or content. (Or if there is such a need because the files are randomly sourced from a carousel of third parties probably you should not be using a relational database but something else: Endeca? Python Pandas library?)
The second is the creating tables on the fly. If you have an agreed file structure then you should be loading into standard tables, using either SQL*Loader or external tables according to your circumstances. If you're on 12c maybe SQL*Loader Express Mode could be of interest.
I am migrating some of my workflows from MySQL to MonetDB.
One thing that has hampered my progress so far is the lack of FIND_IN_SET functionality in MonetDB:
> SELECT FIND_IN_SET('b', 'a,b,c,d');
2
I was relying on this functionality for converting domain definitions between two alignments.
Any idea how I could get this function in MonetDB with reasonable performance?
You could try using a regular expression. I recommended this to someone using MySQL who wanted to find more than one needle in a comma-delimited haystack, perhaps it could be adapted to MonetDB?
SELECT name FROM table WHERE CONCAT(',', DataID, ',') REGEXP ',(222|777|400),'
I have a Pesky SSRS report Problem where in the main query of my report has a condition that can have more than 1000 choices and when user selects all it will fail as my backend database is Oracle. I have done some research and found a solution that would work.
Solution is
re-writing the in clause something like this
(1,ColumnName) in ((1,Searchitem1),(1,SearchItem2))
this will work however when I do this
(1,ColumnName) in ((1,:assignedValue))
and pass just one value it works. But when I pass more than one value it fails and gives me ORA-01722: Invalid number error
I have tried multiple combination of the same in clause but nothing is working
any help is appreciated...
Wild guess: your :assignedValue is a comma-separated list of numbers, and Oracle tries to parse it as a single number.
Passing multiple values as a single value for an IN query is (almost) never a good idea - either you have to use string concatenation (prone to SQL injection and terrible performance), or you have to have a fixed number of arguments to IN (which generally is not what you want).
I'd suggest you
INSERT your search items into a temporary table
use a JOIN with this search table in your SELECT
How do you guys treat empty strings with Oracle?
Statement #1: Oracle treats empty string (e.g. '') as NULL in "varchar2" fields.
Statement #2: We have a model that defines abstract 'table structure', where for we have fields, that can't be NULL, but can be "empty". This model works with various DBMS; almost everywhere, all is just fine, but not with Oracle. You just can't insert empty string into a "not null" field.
Statement #3: non-empty default value is not allowed in our case.
So, would someone be so kind to tell me - how can we resolve it?
This is why I've never understood why Oracle is so popular. They don't actually follow the SQL standard, based on a silly decision they made many years ago.
The Oracle 9i SQL Reference states (this has been there for at least three major versions):
Oracle currently treats a character value with a length of zero as null. However, this may not continue to be true in future releases, and Oracle recommends that you do not treat empty strings the same as nulls.
But they don't say what you should do. The only ways I've ever found to get around this problem are either:
have a sentinel value that cannot occur in your real data to represent NULL (e.g, "deoxyribonucleic" for a surname field and hope that the movie stars don't start giving their kids weird surnames as well as weird first names :-).
have a separate field to indicate whether the first field is valid or not, basically what a real database does with NULLs.
Are we allowed to say "Don't support Oracle until it supports the standard SQL behaviour"? It seems the least pain-laden way in many respects.
If you can't force (use) a single blank, or maybe a Unicode Zero Width Non-Break Space (U+FEFF), then you probably have to go the whole hog and use something implausible such as 32 Z's to indicate that the data should be blank but isn't because the DBMS in use is Orrible.
Empty string and NULL in Oracle are the same thing. You want to allow empty strings but disallow NULLs.
You have put a NOT NULL constraint on your table, which is the same as a not-an-empty-string constraint. If you remove that constraint, what are you losing?