SQL if exists

[Dschainers]

IF EXISTS (SELECT MANDKZ2 FROM DMANDKZ2 WHERE MANDKZ2 = 'DEBID' AND MANDKZW2 = ' ' AND DSGLOEKZ <> 'L') then
.....
ELSE
.....
end if

Diese Abfrage funktioniert nicht, wenn ich sie direkt im STRSQL eingebe.
Was muss ich tun, damit sie funktioniert?
In Prozeduren funktioniert sie!

Vielen Dank für die Antworten.

Viele Grüße
Dschainers

[Fuerchau]

Was hat das mit SQL zu tun?
Korrektes SQL ist:

select bla
from blub
where exists (select * from blubblub where blub.bla = blublub.bla)

Zu beachten ist der "*" im Exists, da die Felder nicht relevant sind für die Existenzprüfung.

[Dschainers]

OK vielen Dank

Grüße
Dschainers

[Dschainers]

Ich wollte eigentlich wissen ob "if exists" im STRSQL funktioniert oder ob ich dafür eine Prozedur anlegen muss.
Auf dem Microsoft SQL Server kann ich "if exists" einfach mal eingeben und es funktioniert.

[Dschainers]

Wir haben nämlich bei uns SQL Server Experten, die sagen daß die Abfrage

SELECT COUNT(*) FROM D_FWABUS WHERE MANDKENN LIKE 'EW1%'

durch eine Abfrage

IF EXISTS(SELECT MANDKENN FROM D_FWABUS WHERE MANDKENN LIKE 'EW1%')
SELECT 1
ELSE
SELECT 0


ersetzt werden soll, da die 2te Abfrage viel schneller ist.

Jetzt wollte ich dies mit STRSQL auf der AS400 ausprobieren, leider funktioniert dies dort nicht

[B.Hauser]

Count(*) zählt auch alles ab und bei vielen Sätzen, ohne entsprechenden (Encoded) Vector Index, kann das schon dauern!
Wenn Du nur wissen willst, ob ein Satz vorhanden ist oder nicht, solltest Du mit FETCH FIRST ROW ONLY oder LIMIT (ist im Übrigen SQL Standard!) oder mit EXISTS (wie Baldur erklärt hat) oder mit Values() arbeiten:


Select 1
from D_FWABUS
Where MANDKENN like 'EWI%'
Fetch First Row Only;


Und wenn Du unbedingt ein "IF" haben willst, kannst Du die Abfrage auch so machen:

Values(Case When (SELECT 1 FROM D_FWABUS WHERE MANDKENN LIKE 'EW1%' Fetch First Row Only) = 1
Then 1
else 0 End);

Es ist allerdings zu beachten, dass SQL Server keine Db2 for i ist und die Datenbanken unterschiedlich optimieren. Der Query Optimizer auf der i kann durch die Kommunikation mit dem Statistics Manager und weil die Statistiken auch immer aktuell sind, auch die Summe relativ fix ermitteln.

... und dann solltest Du Tests nicht (mehr) mit STRSQL, sondern mit ACS machen!

Birgitta

[Fuerchau]

Wobei es bei ACS keinen Unterschied im SQL zu STRSQL gibt.
Microsoft SQL-Server war und ist immer schon was besonderes und hat halt viele Non-SQL-Erweiterungen, die mit SQL-Standard nur wenig bis gar nichts zu tun hat.
Somit lassen sich SQL-Server SQL's häufig gar nicht auf die DB2 for i anwenden.

SQL-Server:
select current date;

DB2:
values(current date)

SQL-Server:
select bla into newtable
from oldtable where ...

db2:
create table newtable as
(select * from oldtable)
with data

usw. usf.
Und das Allerschlimmste: SQL-Server ist ein schlechterer Optimierer als unsere DB2 und macht grundsätzlich "pessimistische" Locks.
Letzteres bedeutet:
Solange eine "Select xxx" nicht beendet ist, also alle Daten abgerufen sind, sind alle betroffenen Tabellen insgesamt gegen veränderungen gesperrt.
Das selbe gilt für alle Update/Delete/Inserts. Diese sperren die Tabellen bis ein Commit/Rollback durchgeführt wird.
Dadurch erklären sich auch manche seltsamen SQL-Konstrukte dieser DB.

[Dschainers]

Vielen Dank an Birgitta

Grüße
Dschainers

[holgerscherer]

Wir haben nämlich bei uns SQL Server Experten

Wie können (Microsoft) SQL-Server-Experten wissen, wie eine IBM i tickt? Ansonsten siehe Biggi.

Und -> in modernen Zeiten iACS nehmen, es kann sein, daß STRSQL nicht bei allen Spielarten von SQL mitspielt.

[Dschainers]

Unser Programmpaket muss sowohl am SQL Server als auf auf der AS400 DB lauffähig sein.
Jetzt haben sich unsere SQL Server Experten neue SQL Anweisungen ausgedacht, diese können leider nicht 1:1 auf der AS400 umgesetzt werden.
Deshalb meine Anfrage hier.

Jetzt ist erstmal alles gut.
Der Fall ist erledigt.

Viele Grüße
Dschainers