Equivalent to minus in netezza - sql

I want to compare data between two different db tables in netezza. In oracle we can do that by minus operator. How can the same operation be done in netezza.
SELECT CUSTOMER_SRC_ID,CUSTOMER_SRC_DESC FROM CIDB_SIT..CUSTOMER_SRC
MINUS
SELECT CUSTOMER_SRC_ID,CUSTOMER_SRC_DESC FROM EDW_SIT..CUSTOMER_SRC
Seems like it doesn't work in netezza. Can any one help me find the equivalent query in netezza?

The ANSI-SQL standard calls this operators except. Netezza implements it, as do PostgreSQL and MS SQL Server:
SELECT CUSTOMER_SRC_ID,CUSTOMER_SRC_DESC FROM CIDB_SIT..CUSTOMER_SRC
EXCEPT -- Here
SELECT CUSTOMER_SRC_ID,CUSTOMER_SRC_DESC FROM EDW_SIT..CUSTOMER_SRC

You could use the EXCEPT
or
--if customer_src_id is unique--
SELECT CUSTOMER_SRC_ID,CUSTOMER_SRC_DESC
FROM CIDB_SIT..CUSTOMER_SRC
WHERE CUSTOMER_SRC_ID NOT IN (SELECT CUSTOMER_SRC_ID FROM EDW_SIT..CUSTOMER_SRC);

Related

Legacy Sql equivalent to TABLE_QUERY(dataset, expr) in standard sql

Can anyone help me with understanding the equivalent of TABLE_QUERY(dataset, expr) in Standard Sql.
I found this on google docs for Legacy Sql:
#legacySQL
SELECT
speed
FROM (TABLE_QUERY([myproject-1234:mydata],
'table_id CONTAINS "oo" AND length(table_id) >= 4'))
I did not find the equivalent for above in Standard SQl
#standardSQL
SELECT speed
FROM `myproject-1234.mydata.*`
WHERE _TABLE_SUFFIX LIKE '%oo%'
AND LENGTH(_TABLE_SUFFIX) >= 4
Important: using just * as a wildcard for whole table name as in myproject-1234.mydata.* is the worst case performance wise
Ideally your table suffix should be as narrow as you can use - like for example myproject-1234.mydata.myprefix_
Read more about Wildcard Tables
Also, here you can read more about Migrating legacy SQL table wildcard functions

What is Teradata's "like any" syntax in oracle?

I am converting Teradata syntax to Oracle.
I have this
SELECT * FROM TABLE_A
WHERE proc_name LIKE any ('%AB%','%AC%')
in Teradata but it is not supported in Oracle.
Does anyone know what is the alternative syntax of Like any in Oracle?
Thanks a lot!
Use or:
SELECT *
FROM TABLE_A
WHERE proc_name LIKE '%AB%' or
proc_name LIKE '%AC%';
This is the "normal" way the logic would be expressed in SQL.
Oracle also supports regular expressions, so if you prefer:
SELECT *
FROM TABLE_A
WHERE regexp_like(proc_name, 'AB|AC');
The two likes probably have better performance.

Sub-Queries in Sybase SQL

We have an application which indexes data using user-written SQL statements. We place those statements within parenthesis so we can limit that query to a certain criteria. For example:
select * from (select F_Name from table_1)q where ID > 25
Though we have discovered that this format does not function using a Sybase database. Reporting a syntax error around the parenthesis. I've tried playing around on a test instance but haven't been able to find a way to achieve this result. I'm not directly involved in the development and my SQL knowledge is limited. I'm assuming the 'q' is to give the subresult an alias for the application to use.
Does Sybase have a specific syntax? If so, how could this query be adapted for it?
Thanks in advance.
Sybase ASE is case sensitive w.r.t. all identifiers and the query shall work:
as per #HannoBinder query :
select id from ... is not the same as select ID from... so make sure of the case.
Also make sure that the column ID is returned by the Q query in order to be used in where clause .
If the table and column names are in Upper case the following query shall work:
select * from (select F_NAME, ID from TABLE_1) Q where ID > 25

SQL to return fixed data in both SQL Server and Oracle

I need a common select statement that returns a fixed value / row without the need of tables, which has to work with both Oracle & Sql Server.
eg for Oracle I know I can use:
select 'O' AS INDICATOR from DUAL;
But this won't work on Sql Server.
Can this be done with the same SQL on both Oracle & SQL Server?
AFAIK, you'll need different queries, unless you can find a table that exists both on the SQL Server and on the Oracle Server.
Oracle uses the DUAL table for dummy queries, while the syntax to just select a constant on SQL server is a bit simpler:
select 'O' as Indicator
will return a one-row recordset.
P.S. If you intend to write just standard SQL and have it work on both SQL Server and Oracle, note that there are lots and lots of differences, even if you do not use database-side code (stored procedures and functions).
Off the top of my head, some things that are different:
Case statement syntax
NVL vs IsNull
Null sorting behaviour
Data conversion functions
String manipulation functions
etc, etc.
You can't select data in Oracle without from statement. So you need to have a table in Oracle (common practice is to use standard table - Dual). The best solution if you really need to run same query on both database servers is to create Dual table with only one row in MS SQL. But really it's better to use different queries for different servers (maybe via some abstraction layer).
Use a common table expression (CTE) e.g.
WITH D (INDICATOR)
AS
(
SELECT *
FROM (
VALUES ('O')
) T (c1)
)
SELECT INDICATOR
FROM D;
Or more simply in line:
SELECT *
FROM (
VALUES ('O')
) D (INDICATOR)
You can create the DUAL table in SQL Server:
CREATE TABLE DUAL (DUMMY NVARCHAR(1) NOT NULL);
INSERT INTO DUAL VALUES ('X');
and then use the same query as in Oracle:
select 'O' AS INDICATOR from DUAL;

Oracle SQL Syntax: With clause

I'm currently using the Java Version of General SQL Parser for Oracle for some relatively complex Oracle SQL Queries.
As in my case I have no access to any Oracle DB but only have the SQL statements in a file I encounter some statements where the parser fails, one particular boils down to following.
select id from (
with foo as (
select bar from sometable
)
select *
from foo
)
The with clause can be parsed without problem, if not nested.
with foo as (
select bar from sometable
)
select *
from foo
So do I have a bug in the parser or in the statement?
Best,
Will
The SQL statement is valid, so I guess the parser just can't handle it.
To be sure, try running the SQL in SQL Plus.
This is a perfectly valid statement in Oracle (I just tried it).
But it might not be valid ANSI SQL and that might be the reason why the parser doesn't understand it.