Dieses Kapitel behandelt besondere Aspekte, die zu berücksichtigen sind, wenn native Natural-DML-Statements und Natural-Systemvariablen zusammen mit Natural-SQL-Statements und Db2 verwendet werden.
Es handelt sich um eine Übersicht über Informationen, die in der Natural-Statements- bzw. -Systemvariablen-Dokumentation ausführlich vorhanden sind.
Eine Erklärung der Symbole, die in diesem Abschnitt zur Darstellung der Syntax von Natural-Statements verwendet werden, finden Sie unter Syntax-Symbole in der Natural-Statements-Dokumentation.
Informationen zur Protokollierung der in einem Natural-Programm enthaltenen SQL-Statements finden Sie unter
DBLOG Trace-Bildschirm für SQL-Statements in der Debugger und Dienstprogramme (Utilities)-Dokumentation.
In diesem Kapitel werden die folgenden Themen behandelt:
Natural for Db2 aktualisiert die folgenden speziellen Db2-Registerr automatisch auf die Werte, die für die zuletzt ausgeführte Transaktion galten.
CURRENT SQLID
CURRENT SCHEMA
CURRENT PATH
CURRENT PACKAGE PATH
Die Inhalte der folgenden Db2-Spezialregister aktualisiert Natural for Db2 nur dann
automatisch auf die Werte, die für die zuletzt ausgeführte Transaktion galten, wenn der
Parameter REFRESH=ON gesetzt ist.
CURRENT PACKAGESET
CURRENT SERVER
Diese speziellen Register werden unabhängig davon aufgefrischt, ob die zuvor ausgeführte Transaktion rückgängig gemacht (Rollback) oder festgeschrieben (Commit) wurde.
Alle anderen speziellen Register werden von Natural for Db2 nicht implizit beeinflusst.
Dieser Abschnitt fasst bestimmte Punkte zusammen, die Sie beachten müssen, wenn Sie Natural-DML-Statements mit Db2 benutzen. Alle Natural-Statements, die in diesem Abschnitt nicht erwähnt werden, können ohne Einschränkung mit Db2 verwendet werden.
Eine Übersicht über die Natural-DML- und SQL-Statements finden Sie im Abschnitt Datenbankzugriffe und Datenbankänderungen in der Natural-Statements-Dokumentation.
Im Folgenden finden Sie Informationen zu den folgenden Natural-DML-Statements:
Das native Natural DML-Statement BACKOUT
TRANSACTION macht alle Datenbanktransaktionen rückgängig, die seit
dem Beginn der letzten logischen Transaktion vorgenommen wurden. Logische Transaktionen
können entweder nach dem Beginn einer Sitzung oder nach der letzten
SYNCPOINT-, END
TRANSACTION- oder BACKOUT TRANSACTION-Statement
beginnen.
Wie das Statement umgesetzt wird und welches Kommando tatsächlich abgesetzt wird, hängt von der TP-Monitor-Umgebung ab:
Wenn dieses Kommando innerhalb einer Natural Stored Procedure oder Natural
User-Defined Function (UDF) ausgeführt wird, führt Natural for Db2 die zugrunde
liegende Rollback-Operation aus. Dadurch wird der Aufrufer in einen
Must-Rollback-Zustand versetzt. Wenn dieses Kommando innerhalb einer
Natural-Stored-Procedure oder einer UDF für Natural-Fehlerverarbeitung (implizites
ROLLBACK) ausgeführt wird, führt Natural for Db2 die zugrunde
liegende Rollback-Operation nicht aus, so dass der Aufrufer den ursprünglichen
Natural-Fehler erhalten kann.
Unter CICS wird das Statement BACKOUT TRANSACTION in ein
EXEC CICS ROLLBACK-Kommando übersetzt. Im
Pseudo-Conversational Mode werden jedoch nur die Änderungen rückgängig gemacht, die
seit der letzten Terminal-E/A an der Datenbank vorgenommen wurden. Dies liegt an der
CICS-spezifischen Transaktionsverarbeitung, siehe Natural for Db2 unter
CICS.
Anmerkung
Beachten Sie, dass Natural bei Terminaleingaben in Datenbankschleifen in den
Conversational Mode wechselt, wenn kein File Server verwendet wird.
Im Batch-Modus und unter TSO wird das BACKOUT TRANSACTION-Statement in
ein SQL ROLLBACK-Kommando übersetzt.
Anmerkung
In einer DSNMTV01-Umgebung wird das BACKOUT
TRANSACTION-Statement ignoriert, wenn der verwendete PSB ohne die Option
CMPAT=YES generiert wurde.
Unter IMS TM wird das BACKOUT TRANSACTION-Statement in ein
IMS-Rollback-Kommando (ROLB) übersetzt. Es werden jedoch
nur die Änderungen an der Datenbank rückgängig gemacht, die seit der letzten
Terminal-E/A vorgenommen wurden. Dies liegt an der IMS TM-spezifischen
Transaktionsverarbeitung, siehe Natural for Db2 unter IMS TM.
Da alle Cursors geschlossen werden, wenn eine logische Arbeitseinheit endet, darf ein
BACKOUT TRANSACTION-Statement nicht innerhalb einer Datenbankschleife
stehen, sondern muss außerhalb einer solchen Schleife oder nach der äußersten Schleife
von geschachtelten Schleifen stehen.
Wenn ein externes Programm, das in einer anderen Standardprogrammiersprache geschrieben
wurde, von einem Natural-Programm aufgerufen wird, darf dieses externe Programm kein
eigenes ROLLBACK-Kommando enthalten, wenn das
Natural-Programm ebenfalls Datenbankaufrufe tätigt. Das aufrufende Natural-Programm muss
das BACKOUT TRANSACTION-Statement für das externe Programm absetzen.
Versucht ein Programm, Änderungen zurückzunehmen (Backout), die bereits festgeschrieben (Commit) wurden, z.B. durch eine Terminal-E/A, so wird eine entsprechende Natural-Fehlermeldung (NAT3711) zurückgegeben.
Das native Natural DML-Statement DELETE wird verwendet, um eine Zeile aus einer Tabelle zu
löschen, die mit einem vorangegangenen FIND-, READ- oder SELECT-Statement gelesen wurde. Es entspricht dem
SQL-Statement DELETE WHERE CURRENT OF
cursor-name, was bedeutet, dass nur die zuletzt
gelesene Zeile gelöscht werden kann.
Beispiel:
FIND EMPLOYEES WITH NAME = 'SMITH'
AND FIRST_NAME = 'ROGER'
DELETE
Natural übersetzt die obigen Natural-Statements in SQL und vergibt einen Cursornamen
(z.B. CURSOR1) wie folgt:
DECLARE CURSOR1 CURSOR FOR SELECT FROM EMPLOYEES WHERE NAME = 'SMITH' AND FIRST_NAME = 'ROGER' FOR UPDATE OF NAME DELETE FROM EMPLOYEES WHERE CURRENT OF CURSOR1
Sowohl das SELECT- als auch das DELETE-Statement beziehen
sich auf denselben Cursor.
Natural übersetzt ein natives Natural-DML-DELETE-Statement in ein
Natural-SQL-DELETE-Statement auf die gleiche Weise, wie es ein natives
Natural-DML-FIND-Statement in ein Natural-SQL-SELECT-Statement übersetzt.
Eine mit einem FIND SORTED
BY-Statement gelesene Zeile kann aufgrund der beim FIND-Statement beschriebenen
Db2-Einschränkungen nicht gelöscht werden. Eine mit READ LOGICAL gelesene Zeile kann
ebenfalls nicht gelöscht werden.
Wenn eine auf den File Server ausgelagerte Zeile gelöscht werden soll, liest Natural
automatisch die ursprüngliche Zeile aus der Datenbank ein und vergleicht sie mit ihrem
auf dem File Server gespeicherten Abbild. Wenn die ursprüngliche Zeile in der
Zwischenzeit nicht geändert wurde, wird die DELETE-Operation durchgeführt.
Bei der nächsten Terminal-E/A wird die Transaktion beendet, und die Zeile wird aus der
aktuellen Datenbank gelöscht.
Wenn die DELETE-Operation auf einen scrollbaren Cursor wirkt, wird die
Zeile auf dem File Server als "freier Datenbereich durch Löschen"
(DELETE-Hole) markiert und aus der Basistabelle gelöscht.
Wird jedoch eine Änderung festgestellt, so wird die Zeile nicht gelöscht und Natural gibt die Fehlermeldung NAT3703 für nicht scrollbare Cursor aus.
Wenn das DELETE auf einen scrollbaren Cursor wirkt, simuliert Natural for
Db2 zwecks Konformität mit Db2 den SQLCODE -224 THE RESULT TABLE DOES NOT AGREE
WITH THE BASE TABLE USING.
Wenn das DELETE auf einen scrollbaren Cursor wirkt und die Zeile zu einem
"freien Datenbereich durch Löschen" (DELETE-Hole) geworden
ist, simuliert Natural for Db2 den SQLCODE -222 AN UPDATE OR DELETE OPERATION WAS
ATTEMPTED AGAINST A HOLE.
Da ein DELETE-Statement erfordert, dass Natural eine einzelne Zeile erneut
liest, muss ein eindeutiger Index für die entsprechende Tabelle vorhanden sein. Alle
Spalten, die den eindeutigen Index bilden, müssen Teil der entsprechenden Natural-View
sein.
Das native DML-Statement END
TRANSACTION zeigt das Ende einer logischen Transaktion an und gibt
alle während der Transaktion gesperrten Db2-Daten frei. Alle Datenänderungen werden
übergeben (Commit) und dauerhaft gemacht.
Wie das Statement übersetzt wird und welches Kommando tatsächlich ausgegeben wird, hängt von der TP-Monitor-Umgebung ab:
Wenn dieses Kommando aus einer Natural Stored Procedure oder einer User Defined Function (UDF) ausgeführt wird, führt Natural for Db2 die zugrunde liegende Commit-Operation nicht aus. Dadurch kann die Stored Procedure oder UDF Änderungen (Updates) gegen Nicht-Db2-Datenbanken vornehmen (Commit).
Unter CICS wird das END TRANSACTION-Statement in ein EXEC
CICS SYNCPOINT-Kommando übersetzt. Wenn der File Server verwendet
wird, wird nach jeder Terminal-E/A ein implizites Transaktionsende (End of
Transaction) abgesetzt. Dies liegt an der CICS-spezifischen Transaktionsverarbeitung
im Pseudo-Conversational Mode, siehe Natural for Db2 unter CICS.
Im Batch-Modus und unter TSO wird das END TRANSACTION-Statement in ein
SQL-Kommando COMMIT WORK übersetzt.
Anmerkung
In einer DSNMTV01-Umgebung wird das END
TRANSACTION-Statement ignoriert, wenn der verwendete PSB ohne die Option
CMPAT=YES erzeugt wurde.
Unter IMS TM wird das END TRANSACTION-Statement nicht in einen IMS
CHKP-Aufruf übersetzt, sondern ignoriert. Aufgrund der IMS TM-spezifischen
Transaktionsverarbeitung (siehe Natural for Db2 unter IMS TM) wird nach jeder
Terminal-E/A ein implizites Transaktionsende (End of Transaction) ausgegeben.
Außer in Kombination mit der WITH HOLD-Klausel (siehe SELECT - SQL unter Verwendung von Natural
SQL-Statements) darf ein END TRANSACTION-Statement
nicht innerhalb einer Datenbankschleife stehen, da alle Cursor geschlossen werden, wenn
eine logische Arbeitseinheit endet. Stattdessen muss sie außerhalb einer solchen
Schleife bzw. bei geschachtelten Schleifen nach der äußersten Schleife stehen.
Wird ein externes Programm, das in einer anderen Standardprogrammiersprache geschrieben
wurde, von einem Natural-Programm aufgerufen, darf dieses externe Programm kein eigenes
COMMIT-Kommando enthalten, wenn das Natural-Programm
ebenfalls Datenbankaufrufe tätigt. Das aufrufende Natural-Programm muss das END
TRANSACTION-Statement für das externe Programm absetzen.
Anmerkung
Bei Db2 kann das END TRANSACTION-Statement nicht verwendet werden, um
Transaktionsdaten zu speichern.
Das native Natural-DML-Statement FIND entspricht dem Natural SQL-Statement SELECT.
Beispiel:
Native Natural-DML-Statements:
FIND EMPLOYEES WITH NAME = 'BLACKMORE' AND AGE EQ 20 THRU 40 OBTAIN PERSONNEL_ID NAME AGE
Äquivalentes Natural-SQL-Statement:
SELECT PERSONNEL_ID, NAME, AGE
FROM EMPLOYEES
WHERE NAME = 'BLACKMORE'
AND AGE BETWEEN 20 AND 40
Natural übersetzt intern ein FIND-Statement in ein SQL-SELECT-Statement. Siehe
Beschreibung in Verarbeitung von
SQL-Statements, die von Natural ausgegeben werden im Abschnitt
Interne Behandlung dynamischer
Statements. Das SELECT-Statement wird von einem
OPEN CURSOR-Statement, gefolgt von einem
FETCH-Kommando, ausgeführt. Das
FETCH-Kommando wird so oft ausgeführt, bis entweder alle
Sätze gelesen wurden oder der Programmablauf die FIND-Verarbeitungsschleife
verlässt. Ein CLOSE CURSOR-Kommando beendet die
SELECT-Verarbeitung.
Die WITH-Klausel
eines FIND-Statements wird in die WHERE-Klausel des
SELECT-Statements umgesetzt. Das Basissuchkriterium für eine Db2-Tabelle
kann auf die gleiche Weise wie für eine Adabas-Datei angegeben werden. Das bedeutet,
dass nur Datenbankfelder, die als Deskriptoren definiert sind, zum Aufbau von
Basissuchkriterien verwendet werden können und dass Deskriptoren nicht mit anderen
Feldern der Natural-View (d.h. Datenbankfeldern) verglichen werden können, sondern nur
mit Programmvariablen oder Konstanten.
Anmerkung
Da jedes Datenbankfeld (Spalte/Column) einer Db2-Tabelle für die Suche verwendet
werden kann, kann ein beliebiges Datenbankfeld als Deskriptor in einem Natural-DDM
definiert werden.
Die WHERE-Klausel
des FIND-Statements wird von Natural ausgewertet, nachdem die
Zeilen über die WITH-Klausel ausgewählt worden sind. Innerhalb der
WHERE-Klausel können Nicht-Deskriptoren verwendet werden und
Datenbankfelder können mit anderen Datenbankfeldern verglichen werden.
Anmerkung
Db2 kennt keine Sub-, Super- oder phonetischen Deskriptoren.
Ein FIND
NUMBER-Statement wird in ein SELECT-Statement mit einer
COUNT(*)-Klausel übersetzt. Die Anzahl der gefundenen Zeilen wird in der
Natural-Systemvariablen *NUMBER zurückgegeben. Beschreibung siehe
Natural-Systemvariablen-Dokumentation.
Das FIND
UNIQUE-Statement kann verwendet werden, um sicherzustellen, dass nur
ein Datensatz für die Verarbeitung ausgewählt wird. Wenn das FIND
UNIQUE-Statement von einem UPDATE-Statement referenziert wird, wird
eine UPDATE-Operation ohne Cursor (Searched) anstelle einer
cursororientierten (Positioned) UPDATE-Operation generiert. Daher können Sie es
verwenden, wenn Sie einen Db2-Primärschlüssel aktualisieren möchten. Es wird jedoch
empfohlen, zur Aktualisierung eines Primärschlüssels das Natural SQL Searched UPDATE-Statement zu
verwenden.
Im statischen Modus werden die Statements FIND NUMBER und FIND
UNIQUE in ein SELECT
SINGLE-Statement übersetzt. Siehe Abschnitt Verwendung von Natural
SQL-Statements.
Das FIND
FIRST-Statement kann nicht verwendet werden. Die Klauseln PASSWORD, CIPHER, COUPLED und RETAIN können ebenfalls
nicht verwendet werden.
Die SORTED
BY-Klausel eines FIND-Statements wird in die SQL-Klausel
SELECT ... ORDER
BY übersetzt, die auf das Suchkriterium folgt. Da dies eine
schreibgeschützte Ergebnistabelle ergibt, kann eine mit einem
FIND-Statement gelesene Zeile, die eine SORTED BY-Klausel
enthält, nicht aktualisiert oder gelöscht werden.
Bei der Installation kann eine Grenze für die Tiefe der verschachtelten Datenbankschleifen festgelegt werden. Wird diese Grenze überschritten, so wird eine Natural-Fehlermeldung ausgegeben.
Anmerkungen:
FIND (5), wird der Grenzwert in eine FETCH FIRST integer ROWS
ONLY-Klausel im generierten SQL-String übersetzt.
MULTIFETCH-Klausel des FIND-Statements.
Hinsichtlich der Nutzung des File Servers gibt es keine programmtechnischen Einschränkungen bei den Auswahl-Statements. Es ist jedoch empfehlenswert, sich mit der Funktionalität vertraut zu machen, um die Leistungsfähigkeit und den Platzbedarf des File Servers zu berücksichtigen.
Das Natural DML-Statement HISTOGRAM gibt die Anzahl der Zeilen in einer Tabelle zurück,
die in einer bestimmten Spalte den gleichen Wert haben. Die Anzahl der Zeilen wird in
der Natural-Systemvariablen *NUMBER zurückgegeben. Siehe
Natural-Systemvariablen-Dokumentation.
Beispiel:
Native Natural-DML-Statements:
HISTOGRAM EMPLOYEES FOR AGE OBTAIN AGE
Äquivalentes Natural-SQL-Statement:
SELECT COUNT(*), AGE FROM EMPLOYEES WHERE AGE > -999 GROUP BY AGE ORDER BY AGE
Natural übersetzt das HISTOGRAM-Statement in ein
SQL-SELECT-Statement, d.h. der Kontrollfluss ist ähnlich wie beim FIND-Statement beschrieben.
Anmerkung
Mit dem Universal Database Server for z/OS Version 8 unterstützt Natural for Db2 die
Verarbeitung mehrerer Zeilen in Db2 im Rahmen der MULTIFETCH-Klausel des HISTOGRAM-Statements.
Das native Natural-DML-Statement READ kann auch für den Zugriff auf Db2-Tabellen verwendet
werden. Natural übersetzt ein READ-Statement in ein SQL SELECT-Statement.
READ PHYSICAL und
READ LOGICAL können
verwendet werden. READ BY
ISN kann jedoch nicht verwendet werden, da es keine Db2-Entsprechung
zu Adabas-ISNs gibt. Die Klauseln PASSWORD und CIPHER können auch nicht verwendet werden.
Da ein READ LOGICAL-Statement in ein SELECT ... ORDER
BY-Statement übersetzt wird, das eine schreibgeschützte Tabelle
erzeugt, kann eine mit einem READ LOGICAL-Statement gelesene Zeile nicht
geändert oder gelöscht werden (siehe Beispiel 1). Der Startwert kann nur eine Konstante
oder eine Programmvariable sein; ein anderes Feld der Natural-Ansicht (d.h. ein
Datenbankfeld) kann nicht verwendet werden.
Ein READ PHYSICAL-Statement wird in ein SELECT-Statement ohne
ORDER BY-Klausel übersetzt und kann daher aktualisiert oder gelöscht
werden (siehe Beispiel 2).
Beispiel 1:
Natives Natural-DML-Statement:
READ PERSONNEL BY NAME OBTAIN NAME FIRSTNAME DATEOFBIRTH
Äquivalentes Natural-SQL-Statement:
SELECT NAME, FIRSTNAME, DATEOFBIRTH FROM PERSONNEL
WHERE NAME >= ' '
ORDER BY NAME
Beispiel 2:
Native Natural-DML-Statements:
READ PERSONNEL PHYSICAL OBTAIN NAME
Äquivalentes Natural-SQL-Statement:
SELECT NAME FROM PERSONNEL
Wenn das READ-Statement eine WHERE-Klausel enthält, wird diese Klausel vom
Natural-Prozessor ausgewertet, nachdem die Zeilen gemäß dem (den) im
Suchkriterium angegebenen Deskriptorwert(en) ausgewählt wurden.
Wenn eine Verarbeitungsgrenze als konstante Ganzzahl, z.B. READ (5), im
generierten SQL-String angegeben ist, wird der Wert, der die Grenze definiert, in die
Klausel übersetzt:
FETCH FIRST
integer
ROWS ONLY |
Natural for Db2 verwendet insensitive scrollbare Cursors, um das folgende READREAD-Statement zu verarbeiten:
READ
.. [IN] [LOGICAL] VARIABLE/DYNAMIC
operand5
[SEQUENCE] |
Natural for Db2 verwendet insensitive scrollbare Cursors, um das folgende
READ-Statement zu verarbeiten. Wenn es sich um ein Positioned
UPDATE- oder Positioned
DELETE-Statement handelt, verwendet Natural for Db2
insensitive statische Cursors.
READ .. [IN] [PHYSICAL] DESCENDING/VARIABLE/DYNAMIC
operand5
[SEQUENCE] |
operand5
Der Wert A wird in einen FETCH FIRST/NEXT-Db2-Zugriff und der Wert
D in einen FETCH LAST/PRIOR-Db2-Zugriff übersetzt.
Anmerkung
Natural for Db2 unterstützt die Db2-Verarbeitung mehrerer Zeilen im Rahmen der
MULTIFETCH-Klausel
im READ-Statement.
Hinsichtlich der Verwendung des File Servers gibt es keine programmtechnischen Einschränkungen bei den Auswahl-Statements. Es ist jedoch empfehlenswert, sich mit der Funktionalität unter Berücksichtigung von Performance und Platzbedarf des File Servers vertraut zu machen.
Das Native Natural-DML-Statement STORE wird verwendet, um eine Zeile zu einer Db2-Tabelle
hinzuzufügen. Das STORE-Statement entspricht dem SQL- Statement INSERT.
Beispiel:
Natives Natural-DML-Statement:
STORE RECORD IN EMPLOYEES
WITH PERSONNEL_ID = '2112'
NAME = 'LIFESON'
FIRST_NAME = 'ALEX'
Äquivalentes Natural SQL-Statement:
INSERT INTO EMPLOYEES (PERSONNEL_ID, NAME, FIRST_NAME)
VALUES ('2112', 'LIFESON', 'ALEX')
Die Klauseln PASSWORD, CIPHER und USING/GIVING
NUMBER des STORE-Statements können nicht verwendet werden.
Das native Natural-DML-Statement UPDATE aktualisiert eine Zeile in einer Db2-Tabelle, die mit
einem vorangegangenen FIND,
READ oder SELECT-Statement gelesen wurde. Sie
entspricht dem SQL-Statement UPDATE WHERE CURRENT OF
cursor-name (Positioned
UPDATE), was bedeutet, dass nur die zuletzt gelesene Zeile
aktualisiert werden kann.
Wenn eine auf den File Server ausgelagerte Zeile aktualisiert werden soll, liest
Natural automatisch die ursprüngliche Zeile aus der Datenbank ein und vergleicht sie
mit ihrem auf dem File Server gespeicherten Abbild. Wenn die ursprüngliche Zeile in
der Zwischenzeit nicht geändert wurde, wird die UPDATE-Operation
durchgeführt. Bei der nächsten Terminal-E/A wird die Transaktion beendet und die Zeile
endgültig in der Datenbank aktualisiert.
Wenn die UPDATE-Operation auf einen scrollbaren Cursor wirkt, werden die
Zeile auf dem File Server und die Zeile in der Basistabelle aktualisiert. Erfüllt die
Zeile nach der Aktualisierung nicht mehr die Suchkriterien des zugehörigen SELECT-Statements, wird die Zeile
auf dem File Server als "freier Datenbereich durch Aktualisieren"
(UPDATE-Hole) markiert.
Wird jedoch eine Änderung festgestellt, wird die Zeile nicht aktualisiert und Natural gibt die Fehlermeldung NAT3703 für nicht scrollbare Cursor aus.
Wenn das UPDATE auf einen scrollbaren Cursor wirkt, simuliert Natural
for Db2 zwecks Konformität mit Db2 den SQLCODE -224 THE RESULT TABLE DOES
NOT AGREE WITH THE BASE TABLE USING.
Wenn das UPDATE auf einen scrollbaren Cursor wirkt und die Zeile ein
"freier Datenbereich durch Aktualisieren" (UPDATE-Hole)
geworden ist, simuliert Natural for Db2 den SQLCODE -222 AN UPDATE OR
DELETE OPERATION WAS ATTEMPTED AGAINST A HOLE.
Da ein UPDATE-Statement das erneute Lesen einer einzelnen Zeile durch
Natural erfordert, muss ein eindeutiger Index für diese Tabelle vorhanden sein. Alle
Spalten, die den eindeutigen Index umfassen, müssen Teil der entsprechenden
Natural-View sein.
Wie beim nativen Natural-DML-Statement FIND beschrieben, übersetzt Natural ein
FIND-Statement in ein SQL SELECT-Statement. Wenn ein Natural-Programm ein DML
UPDATE-Statement enthält, wird dieses Statement in ein SQL
UPDATE-Statement übersetzt und dem SELECT-Statement eine
FOR UPDATE OF-Klausel hinzugefügt.
Beispiel:
FIND EMPLOYEES WITH SALARY < 5000 ASSIGN SALARY = 6000 UPDATE
Natural übersetzt die obigen Natural-Statements in SQL und vergibt einen Cursornamen
(z. B. CURSOR1) wie folgt:
DECLARE CURSOR1 CURSOR FOR SELECT SALARY FROM EMPLOYEES WHERE SALARY < 5000 FOR UPDATE OF SALARY UPDATE EMPLOYEES SET SALARY = 6000 WHERE CURRENT OF CURSOR1
Sowohl das SELECT- als auch das UPDATE-Statement beziehen
sich auf denselben Cursor.
Aufgrund der Db2-Logik kann eine Spalte (ein Feld) nur dann aktualisiert werden, wenn
sie in der FOR UPDATE OF-Klausel enthalten ist. Andernfalls wird das
Aktualisieren dieser Spalte (dieses Feldes) abgelehnt. Natural nimmt automatisch alle
Spalten (Felder) in die FOR UPDATE OF-Klausel auf, die an beliebiger
Stelle im Natural-Programm geändert wurden oder die als Teil einer Natural-Maske (Map)
Eingabefelder sind.
Eine Db2-Spalte wird jedoch nicht aktualisiert, wenn die Spalte (das Feld) im
Natural-DDM als "nicht aktualisierbar" gekennzeichnet ist. Solche Spalten
(Felder) werden ohne Warnung oder Fehlermeldung aus der FOR UPDATE
OF-Liste entfernt. Die in der FOR UPDATE OF-Liste enthaltenen
Spalten (Felder) können mit dem Kommando LISTSQL überprüft werden.
Der Adabas-Kurzname im Natural DDM bestimmt, ob eine Spalte (ein Feld) aktualisiert werden kann.
Die folgende Tabelle zeigt, welche Bereiche gelten:
| Kurzbezeichnungsbereich | Feldtyp |
|---|---|
| AA - N9 | Nicht-Schlüsselfeld, das aktualisiert werden kann. |
| Aa - Nz | Nicht-Schlüsselfeld, das aktualisiert werden kann. |
| OA - O9 | Primärschlüsselfeld. |
| PA - P9 | Aufsteigendes Schlüsselfeld, das aktualisiert werden kann. |
| QA - Q9 | Absteigendes Schlüsselfeld, das aktualisiert werden kann. |
| RA - X9 | Nicht-Schlüsselfeld, das nicht aktualisiert werden kann. |
| Ra - Xz | Nicht-Schlüsselfeld, das nicht aktualisiert werden kann. |
| YA - Y9 | Aufsteigendes Schlüsselfeld, das nicht aktualisiert werden kann. |
| ZA - Z9 | Absteigendes Schlüsselfeld, das nicht aktualisiert werden kann. |
| 1A - 9Z | Nicht-Schlüsselfeld, das nicht aktualisiert werden kann. |
| 1a - 9z | Nicht-Schlüsselfeld, das nicht aktualisiert werden kann. |
Beachten Sie, dass ein Primärschlüsselfeld niemals Teil einer FOR UPDATE
OF-Liste ist. Ein Primarschlüsselfeld kann nur mit einer
UPDATE-Operation ohne Cursor aktualisiert werden (siehe auch das
Natural-SQL-UPDATE-Statement im Abschnitt Verwendung von Natural
SQL Statements.
Beachten Sie, dass ein Primärschlüsselfeld niemals Teil einer FOR UPDATE
OF-Liste ist, außer wenn die Compiler-Option DB2PKYU auf
ON gesetzt ist. Wenn DB2PKYU auf OFF gesetzt
ist, was der Standardwert ist, können Sie ein Primärschlüsselfeld nur mit einer
UPDATE-Operation ohne Cursor aktualisieren. Weitere Informationen
finden Sie auch unter Natural SQL UPDATE-Statement im Abschnitt Verwendung von
Natural SQL-Statements.
Eine mit einem FIND-Statement gelesene Zeile, die eine SORTED BY-Klausel
enthält, kann nicht aktualisiert werden (aufgrund von Db2-Einschränkungen, wie bei dem
FIND-Statement
beschrieben). Eine mit einem READ
LOGICAL-Statement gelesene Zeile kann ebenfalls nicht
aktualisiert werden (wie bei dem READ-Statement beschrieben).
Wenn eine Spalte aktualisiert werden soll, die als Array redefiniert ist, wird
dringend empfohlen, die gesamte Spalte zu aktualisieren und nicht einzelne
Ausprägungen. Andernfalls sind die Ergebnisse nicht vorhersehbar. Dazu können Sie im
Reporting Mode das Statement OBTAIN verwenden, das auf alle Feldausprägungen in der zu
aktualisierenden Spalte angewendet werden muss. Im Structured Mode hingegen müssen
alle diese Ausprägungen in der entsprechenden Natural-View definiert sein.
Die durch ein UPDATE-Statement gesperrten Daten werden freigegeben, wenn
ein Statement END
TRANSACTION (COMMIT WORK) oder BACKOUT TRANSACTION (ROLLBACK
WORK) vom Programm ausgeführt wird.
Anmerkung
Wird in einem Natural-Programm ein Längen-Indikatorfeld oder ein
NULL-Indikatorfeld aktualisiert, ohne dass das Feld (die Spalte), auf das
es sich bezieht, aktualisiert wird, so wird die Aktualisierung der Spalte für Db2
nicht generiert und es erfolgt somit keine Aktualisierung.
Generell kann das native Natural-DML-Statement UPDATE sowohl im
Structured als auch im Reporting Mode verwendet werden. Nach einem
SELECT-Statement ist jedoch nur die für den Natural Structured Mode
definierte Syntax zulässig:
UPDATE [RECORD] [IN] [STATEMENT]
[(r)]
|
Dies liegt daran, dass das native Natural-DML-Statement UPDATE in
Kombination mit dem SELECT-Statement nur im folgenden speziellen Fall
erlaubt ist:
... SELECT ... INTO VIEW view-name ...
Es kann also nur eine ganze Natural-View aktualisiert werden, einzelne Spalten (Felder) nicht.
Beispiel:
DEFINE DATA LOCAL
01 PERS VIEW OF SQL-PERSONNEL
02 NAME
02 AGE
END-DEFINE
SELECT *
INTO VIEW PERS
FROM SQL-PERSONNEL
WHERE NAME LIKE 'S%'
IF NAME = 'SMITH'
ADD 1 TO AGE
UPDATE
END-IF
END-SELECT
...
In Kombination mit dem nativen Natural-DML-Statement UPDATE wird jede
andere Form des SELECT-Statements zurückgewiesen und eine Fehlermeldung
zurückgegeben.
Im übrigen kann das native Natural-DML-Statement UPDATE mit dem
SELECT-Statement genauso wie mit dem Natural-Statement FIND verwendet werden.
Dieser Abschnitt behandelt Punkte, die bei der Verwendung von Natural SQL-Statements mit Db2 zu beachten sind. Diese Db2-spezifischen Punkte bestehen zum Teil aus Syntaxerweiterungen, die zum Extended Set der Natural SQL-Syntax gehören. Das Extended Set wird zusätzlich zum Common Set angeboten, um datenbankspezifische Besonderheiten zu unterstützen. Siehe Common Set und Extended Set in der Statements-Dokumentation.
Informationen zur Protokollierung der in einem Natural-Programm enthaltenen SQL-Statements finden Sie unter DBLOG Trace-Bildschirm für SQL-Statements unter DBLOG Utility in der Debugger und Dienstprogramme (Utilities)-Dokumentation.
Nachfolgend finden Sie Informationen zu den folgenden Natural SQL-Statements und zu gemeinsamen syntaktischen Elementen:
Die folgenden gemeinsamen syntaktischen Elemente sind entweder Db2-spezifisch und entsprechen nicht den Standard-SQL-Syntaxdefinitionen (d.h. dem Common Set der Natural SQL Syntax) oder unterliegen Einschränkungen bei der Verwendung mit Db2 (siehe auch Natural-SQL-Statements benutzen in der Natural-Statements-Dokumentation).
Im Folgenden finden Sie Informationen zu den gemeinsamen syntaktischen Elementen:
Ein atom kann entweder ein Parameter (d.h. eine Natural-Programm- oder Host-Variable) oder eine Konstante sein. Bei der dynamischen Ausführung ist die Verwendung von Host-Variablen jedoch durch Db2 eingeschränkt. Weitere Einzelheiten sind in der entsprechenden Db2-Literatur von IBM zu finden.
Die für Db2 spezifischen Vergleichsoperatoren gehören zum Natural SQL Extended Set. Eine Beschreibung finden Sie unter comparison-predicate in Suchbedingungen in der Statements-Dokumentation.
Die folgenden Faktoren sind Db2-spezifisch und gehören zum Natural SQL Extended Set:
|
special-register |
Eine scalar-function ist eine eingebaute Funktion, die bei der Formulierung von skalaren Berechnungsausdrücken verwendet werden kann. Scalar-functions sind Db2-spezifisch und gehören zum Natural SQL Extended Set.
Die scalar-functions, die Natural for Db2 unterstützt, sind unten in alphabetischer Reihenfolge aufgeführt:
| A - H | I - R | S - Z |
|---|---|---|
|
|
|
|
Auf jede scalar-function folgen ein oder mehrere scalar-expressions in Klammern. Die Anzahl der scalar-expressions hängt von der scalar-function ab. Mehrere scalar-expressions müssen durch Kommata voneinander getrennt werden.
Beispiel:
SELECT NAME
INTO NAME
FROM SQL-PERSONNEL
WHERE SUBSTR ( NAME, 1, 3 ) = 'Fri'
...
Eine column-function gibt ein einwertiges Ergebnis für das Argument zurück, das sie erhält. Das Argument ist eine Menge gleichartiger Werte, z. B. die Werte einer Spalte. Column-functions werden auch aggregate-functions genannt.
Die folgenden column-functions entsprechen dem SQL-Standard. Sie sind nicht Db2-spezifisch:
AVG
COUNT
MAX
MIN
SUM
Die folgenden column-functions sind nicht konform mit dem SQL-Standard. Sie sind Db2-spezifisch und gehören zum Natural SQL Extended Set.
COUNT_BIG
CORRELATION
COVARIANCE
COVAR_POP
COVARIANCE_SAMP
LISTAGG
MEDIAN
PERCENTILE_CONT
PERCENTILE_DISC
REGR_AVGX
REGR_AVGY
REGR_COUNT
REGR_ICPT
REGR_IMTERCEPT
REGR_R2
REGR_SLOPE
REGR_SXX
REGR_SXY
REGR_SYY
STDDEV
STDDEV_POP
STDDEV_SAMP
VAR
VAR_POP
VAR_SAMP
VARIANCE
VARIANCE_SAMP
XMLAGG
Der Verkettungsoperator (CONCAT oder ||) beim scalar-operator entspricht nicht dem
SQL-Standard. Er ist Db2-spezifisch und gehört zum Natural Extended Set.
Mit Ausnahme von USER entsprechen die folgenden special-registers nicht dem SQL-Standard. Sie
sind Db2-spezifisch und gehören zum Natural SQL Extended Set:
CURRENT APPLICATION COMPATIBILITY
CURRENT APPLICATION ENCODING SCHEME
CURRENT CLIENT_ACCNTG
CLIENT ACCNTG
CURRENT CLIENT_APPLNAME
CLIENT APPLNAME
CURRENT CLIENT_USERID
CLIENT USERID
CURRENT CLIENT_WRKSTNNAME
CLIENT WRKSTNNAME
CURRENT DATE
CURRENT_DATE
CURRENT DEBUG MODE
CURRENT DECFLOAT ROUNDING MODE
CURRENT DEGREE
CURRENT FUNCTION PATH
CURRENT GET_ACCEL_ARCHIVE
CURRENT_LC_CTYPE
CURRENT LC_CTYPE
CURRENT LOCALE LC_CTYPE
CURRENT LOCK TIMEOUT
CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION
CURRENT_MEMBER
CURRENT OPTIMIZATION HINT
CURRENT PACKAGE PATH
CURRENT PACKAGESET
CURRENT_PATH
CURRENT PRECISION
CURRENT QUERY ACCELERATION
CURRENT QUERY ACCELERATION WAITFORDATA
CURRENT REFRESH AGE
CURRENT ROUTINE VERSION
CURRENT RULES
CURRENT SCHEMA
CURRENT SERVER
CURRENT_SERVER
CURRENT SQLID
CURRENT TEMPORAL BUSINESS_TIME
CURRENT TEMPORAL_SYSTEM_TIME
CURRENT TIME
CURRENT_TIME
CURRENT TIMESTAMP
CURRENT TIMEZONE
CURRENT_TIMEZONE
CURRENT_TIMEZONE USER
SESSION TIME ZONE
SESSION_USER
USER
Eine Referenz auf ein spezielles Register gibt einen skalaren Wert zurück.
Mit dem Kommando SET CURRENT SQLID kann der Ersteller-Name
(creator) einer Tabelle durch die aktuelle SQLID ersetzt werden. Damit
ist es möglich, auf identische Tabellen mit demselben Tabellennamen, aber mit
unterschiedlichen Ersteller-Namen zuzugreifen.
Units (Einheiten), auch durations genannt, sind Db2-spezifisch und gehören zum Natural SQL Extended Set.
Die folgenden units werden unterstützt:
DAY
DAYS
HOUR
HOURS
MICROSECOND
MICROSECONDS
MINUTE
MINUTES
MONTH
MONTHS
SECOND
SECONDS
YEAR
YEARS
CASE
|
|
searched-when-clause ... |
|
|
ELSE
|
|
|
|
|
END
|
Case-expressions entsprechen nicht dem Standard-SQL und werden daher nur vom Natural SQL Extended Set unterstützt.
DEFINE DATA LOCAL
01 #EMP
02 #EMPNO (A10)
02 #FIRSTNME (A15)
02 #MIDINIT (A5)
02 #LASTNAME (A15)
02 #EDLEVEL (A13)
02 #INCOME (P7)
END-DEFINE
SELECT EMPNO, FIRSTNME, MIDINIT, LASTNAME,
(CASE WHEN EDLEVEL < 15 THEN 'SECONDARY'
WHEN EDLEVEL < 19 THEN 'COLLEGE'
ELSE 'POST GRADUATE'
END ) AS EDUCATION, SALARY + COMM AS INCOME
INTO
#EMPNO, #FIRSTNME, #MIDINIT, #LASTNAME,
#EDLEVEL, #INCOME
FROM DSN8510-EMP
WHERE (CASE WHEN SALARY = 0 THEN NULL
ELSE SALARY / COMM
END ) > 0.25
DISPLAY #EMP
END-SELECT
END
Das Natural SQL-Statement CALLDBPROC wird für den Aufruf von Db2 Stored
Procedures verwendet. Es unterstützt den Ergebnismengenmechanismus
(result-set) von Db2 und ermöglicht den Aufruf von Db2 Stored Procedures.
Weitere Einzelheiten und die Statement-Syntax finden Sie unter CALLDBPROC (SQL) in der
Statements-Dokumentation.
Die folgenden Themen werden behandelt:
Wenn das CALLDBPROC-Statement dynamisch ausgeführt wird, werden alle
Parameter und Konstanten auf die Variablen des folgenden Db2 SQL-Statement
abgebildet:
CALL :hv USING DESCRIPTOR :sqlda statement
:hv bezeichnet eine Host-Variable, die den
Namen der aufzurufenden Prozedur enthält.
:sqlda ist eine dynamisch generierte sqlda,
die die Parameter beschreibt, die an die Stored Procedure übergeben werden sollen.
Wenn das CALLDBPROC-Statement statisch ausgeführt wird, werden die
Konstanten des CALLDBPROC-Statements auch als Konstanten in dem
generierten Assembler SQL-Quellcode für den Db2 Precompiler erzeugt.
Wenn der von dem CALL-Statement erzeugte SQLCODE anzeigt, dass es
Ergebnismengen gibt (SQLCODE +466 und +464), führt die
Natural for Db2-Laufzeit ein DESCRIBE PROCEDURE :hv
INTO : sqlda-Statement aus, um die result
set locator-Werte der von der aufgerufenen Stored Procedure erzeugten
Ergebnismengen abzurufen. Diese Werte werden in die RESULT
SETS-Variablen gestellt, die in dem
CALLDBPROC-Statement angegeben sind. Jede in einem
CALLDBPROC angegebene RESULT SETS-Variable, für die kein
result set locator-Wert vorhanden ist, wird auf Null zurückgesetzt. Die
result set locator-Werte können zum Lesen der Ergebnismengen mit dem
READ RESULT
SET-Statement verwendet werden, solange die Datenbanktransaktion,
die die Ergebnismenge erzeugt hat, noch kein COMMIT oder
ROLLBACK abgesetzt hat.
Wurde die Ergebnismenge durch einen Cursor WITH HOLD
erzeugt, bleibt der result set locator-Wert auch nach einer
COMMIT-Operation gültig.
Im Gegensatz zu anderen Natural SQL-Statements können Sie bei CALLDBPROC
(optional!) nach dem Schlüsselwort GIVING eine
SQLCODE-Variable angeben, die den SQLCODE des zugrunde liegenden CALL-Statements enthält. Wenn
GIVING angegeben wird, ist es Aufgabe des Natural-Programms, auf den
SQLCODE zu reagieren (die Fehlermeldung NAT3700 wird von der Laufzeit nicht
ausgegeben).
Im Folgenden werden die vom Statement CALLDBPROC unterstützten Parameterdatentypen
aufgeführt:
| Natural-Format/Länge | Db2-Datentyp |
|---|---|
| An | CHAR(n) |
| B2 | SMALLINT |
| B4 | INT |
|
Bn
|
CHAR(n) |
| F4 | REAL |
| F8 | DOUBLE PRECISION |
| I2 | SMALLINT |
| I4 | INT |
| Nnn.m | NUMERIC(nn+m,m) |
| Pnn.m | NUMERIC(nn+m,n) |
| Gn | GRAPHIC(n) |
| An/1:m | VARCHAR(n*m) |
| D | DATE |
| T |
TIME
Anmerkung |
Dieser Parameter wird verwendet, um Natural Stored Procedures aufzurufen, die mit
PARAMETER STYLE GENERAL/WITH NULL definiert wurden.
Wenn der Parameter CALLMODE=NATURAL angegeben ist, wird ein zusätzlicher
Parameter, der die an die Natural Stored Procedure übergebenen Parameter beschreibt,
vom Client, d.h. dem Aufrufer, an den Server, d.h. den Natural for Db2 Server Stub,
übergeben. Der Parameter ist der Stored Procedure Control Block (STCB; siehe auch
STCB
Layout in PARAMETER STYLE im Abschnitt Verarbeitung von Natural Stored Procedures und
UDFs) und hat aus Sicht von Db2 das Format
VARCHAR. Daher muss jede Natural Stored Procedure, die mit
PARAMETER STYLE GENERAL/WITH NULL definiert ist, mit dem CREATE
PROCEDURE-Statement definiert werden, indem dieser
VARCHAR-Parameter als erster in seiner
PARMLIST-Zeile verwendet wird.
Aus der Sicht des Aufrufers, d.h. des Natural-Programms, und aus der Sicht der Stored
Procedure, d.h. des Natural-Subprogramms, ist der STCB unsichtbar. Er wird als erster
Parameter von der Natural for Db2-Laufzeit übergeben und auf der Server-Seite
verwendet, um die Kopie der übergebenen Daten im Natural-Thread und dem entsprechenden
CALLNAT-Statement zu
erstellen. Außerdem dient dieser Parameter als Container für Fehlerinformationen, die
während der Ausführung der Natural-Stored-Procedure durch die Natural-Laufzeit erzeugt
werden. Er enthält auch Informationen über die Library, in der Sie angemeldet sind,
und das aufzurufende Natural-Subprogramm.
Nachfolgend finden Sie ein Beispielprogramm für die Ausführung der Statements
CALLDBPROC und
READ RESULT
SET:
DEFINE DATA LOCAL
1 ALPHA (A8)
1 NUMERIC (N7.3)
1 PACKED (P9.4)
1 VCHAR (A20/1:5) INIT <'DB25SGCP'>
1 INTEGER2 (I2)
1 INTEGER4 (I4)
1 BINARY2 (B2)
1 BINARY4 (B4)
1 BINARY12 (B12)
1 FLOAT4 (F4)
1 FLOAT8 (F8)
1 INDEX-ARRAY (I2/1:11)
1 INDEX-ARRAY1(I2)
1 INDEX-ARRAY2(I2)
1 INDEX-ARRAY3(I2)
1 INDEX-ARRAY4(I2)
1 INDEX-ARRAY5(I2)
1 INDEX-ARRAY6(I2)
1 INDEX-ARRAY7(I2)
1 INDEX-ARRAY8(I2)
1 INDEX-ARRAY9(I2)
1 INDEX-ARRAY10(I2)
1 INDEX-ARRAY11(I2)
1 #RESP (I4)
1 #RS1 (I4) INIT <99>
1 #RS2 (I4) INIT <99>
LOCAL
1 V1 VIEW OF SYSIBM-SYSTABLES
2 NAME
1 V2 VIEW OF SYSIBM-SYSPROCEDURES
2 PROCEDURE
2 RESULT_SETS
1 V (I2) INIT <99>
END-DEFINE
CALLDBPROC 'DAEFDB25.SYSPROC.SNGSTPC' DSN8510-EMP
ALPHA INDICATOR :INDEX-ARRAY1
NUMERIC INDICATOR :INDEX-ARRAY2
PACKED INDICATOR :INDEX-ARRAY3
VCHAR(*) INDICATOR :INDEX-ARRAY4
INTEGER2 INDICATOR :INDEX-ARRAY5
INTEGER4 INDICATOR :INDEX-ARRAY6
BINARY2 INDICATOR :INDEX-ARRAY7
BINARY4 INDICATOR :INDEX-ARRAY8
BINARY12 INDICATOR :INDEX-ARRAY9
FLOAT4 INDICATOR :INDEX-ARRAY10
FLOAT8 INDICATOR :INDEX-ARRAY11
RESULT SETS #RS1 #RS2
CALLMODE=NATURAL
READ (10) RESULT SET #RS2 INTO VIEW V2 FROM SYSIBM-SYSTABLES
WRITE 'PROC F RS :' PROCEDURE 50T RESULT_SETS
END-RESULT
END
Das Natural SQL-Statement COMMIT zeigt das Ende einer logischen
Transaktion an und gibt alle während der Transaktion gesperrten Db2-Daten frei. Alle
Datenänderungen werden permanent gemacht. Weitere Einzelheiten und die Statement-Syntax
finden Sie unter COMMIT
(SQL) in der Statements-Dokumentation.
COMMIT ist ein Synonym für das native Natural DML-Statement END TRANSACTION, das im
Abschnitt Verwendung von nativen Natural
DML-Statements beschrieben ist.
Mit dem COMMIT-Statement können keine Transaktionsdaten mitgegeben
werden.
Wenn dieses Statement von einer Natural Stored Procedure oder einer benutzerdefinierten Funktion (UDF) ausgeführt wird, führt Natural for Db2 die zugrunde liegende Commit-Operation nicht aus. Dadurch kann die Natural Stored Procedure bzw. die benutzerdefinierte Funktion (UDF) ein Commit auf Updates bei Nicht-Db2-Datenbanken ausführen.
Unter CICS wird das COMMIT-Statement in ein EXEC CICS
SYNCPOINT-Kommando übersetzt. Wird der File Server verwendet, wird nach
jeder Terminal-E/A ein implizites Transaktionsende ausgegeben. Dies liegt an der
CICS-spezifischen Transaktionsverarbeitung im Pseudo-Conversational Mode, siehe
Natural for Db2 unter
CICS.
Unter IMS TM wird das COMMIT-Statement nicht in ein IMS
CHECKPOINT-Kommando übersetzt, sondern ignoriert. Ein
implizites Transaktionsende wird nach jeder Terminal-E/A ausgegeben. Dies liegt an der
IMS TM-spezifischen Transaktionsverarbeitung, siehe Natural for Db2 unter IMS
TM.
Ein COMMIT-Statement darf nicht innerhalb einer Datenbankschleife stehen,
es sei denn, es wird in Kombination mit der WITH
HOLD-Klausel verwendet (siehe Syntax 1 -
Cursor-orientierte Selektion in SELECT (SQL)
in der Statements-Dokumentation), da alle Cursor am Ende einer
logischen Arbeitseinheit geschlossen werden. Stattdessen muss sie außerhalb einer
solchen Schleife bzw. bei geschachtelten Schleifen nach der äußersten Schleife
stehen.
Wenn ein externes Programm, das in einer anderen Standardprogrammiersprache geschrieben
wurde, von einem Natural-Programm aufgerufen wird, darf dieses externe Programm kein
eigenes COMMIT-Kommando enthalten, wenn das Natural-Programm
ebenfalls Datenbankaufrufe tätigt. Das aufrufende Natural-Programm muss das
COMMIT-Statement für das externe Programm absetzen.
Im Rahmen von Natural SQL werden sowohl das cursororientierte bzw. Positioned
DELETE als auch das nicht-cursororientierte bzw. Searched
DELETE unterstützt. Die Funktionalität des Positioned
DELETE entspricht derjenigen des Natural DML DELETE. Weitere Einzelheiten
und die Statement-Syntax finden Sie unter DELETE (SQL) in der
Natural-Statements-Dokumentation.
Bei Db2 kann ein Tabellenname in der FROM-Klausel eines Searched
DELETE-Statements mit einem correlation-name versehen
werden. Dies entspricht nicht der Standard-SQL-Syntaxdefinition und gehört daher zum
Natural SQL Extended
Set.
Das Searched
DELETE-Statement muss z.B. verwendet werden, um eine Zeile
aus einer selbstreferenzierenden Tabelle zu löschen, da bei selbstreferenzierenden
Tabellen ein Positioned DELETE von Db2 nicht zugelassen wird.
Das Natural SQL INSERT-Statement wird verwendet, um eine oder mehrere neue
Zeilen zu einer Tabelle hinzuzufügen.
Da das INSERT-Statement einen
select-expression enthalten kann, gelten
alle oben beschriebenen Db2-spezifischen gemeinsamen Syntaxelemente.
Weitere Einzelheiten und die Statement-Syntax finden Sie unter INSERT (SQL) in der Natural-Statements-Dokumentation.
Das MERGE-Statement ist ein hybrides SQL-Statement, das aus einer
UPDATE- und einer INSERT-Komponente besteht. Es ermöglicht
Ihnen, entweder eine Zeile in eine Db2-Tabelle einzufügen oder eine Zeile einer
Db2-Tabelle zu aktualisieren, wenn die Eingabedaten mit einer bereits existierenden
Zeile einer Tabelle übereinstimmen.
Das MERGE-Statement gehört zum SQL Extended Set.
Weitere Einzelheiten und die Statement-Syntax finden Sie unter MERGE (SQL) in der Natural-Statements-Dokumentation.
Das Natural PROCESS SQL-Statement wird verwendet, um SQL-Statements an die
zugrunde liegende Datenbank zu senden. Die Statements werden in einem
statement-string angegeben, der auch
Konstanten und Parameter enthalten kann. Der Set von Statements, die ausgegeben werden
können, wird auch als Flexible SQL bezeichnet und umfasst diejenigen Statements, die mit
dem SQL-Statement EXECUTE ausgegeben werden können.
Darüber hinaus umfasst Flexible SQL die folgenden Db2-spezifischen Statements:
CALL
CONNECT
GET DIAGNOSTICS
SET APPLICATION ENCODING SCHEME
SET CONNECTION
SET CURRENT DEGREE
SET CURRENT LC_CTYPE
SET CURRENT OPTIMIZATION HINT
SET CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION
SET CURRENT PACKAGE PATH
SET CURRENT PACKAGESET
SET CURRENT PATH
SET CURRENT PRECISION
SET CURRENT REFRESH AGE
SET CURRENT RULES
SET CURRENT SCHEMA
SET CURRENT SQLID
SET ENCRYPTION PASSWORD
SET
host-variable=special-register
RELEASE
Anmerkungen:
PROCESS SQL ausgegeben werden, werden bei
der statischen Generierung übersprungen. Sie werden daher immer dynamisch über
NDBIOMO
ausgeführt.
COMMIT und ROLLBACK im PROCESS SQL nicht verwendet
werden.
Weitere Einzelheiten und die Statement-Syntax finden Sie unter PROCESS SQL in der Statements-Dokumentation.
Das Natural SQL-Statement READ RESULT SET liest eine Ergebnismenge
(result-set), die von einer Natural Stored
Procedure erzeugt wurde, die durch ein CALLDBPROC-Statement aufgerufen wurde. Wie Sie die
Scroll-Richtung mit Hilfe der Variablen scroll-hv angeben, erfahren Sie beim
SELECT-Statement.
Weitere Einzelheiten und die Statement-Syntax siehe READ RESULT SET (SQL) in der Statements-Dokumentation.
Das Natural SQL-Statement ROLLBACK macht alle Datenbankänderungen rückgängig, die seit
Beginn der letzten logischen Transaktion vorgenommen wurden. Logische Transaktionen
können entweder nach dem Beginn einer Sitzung oder nach dem letzten
COMMIT/END TRANSACTION-Statement oder der
ROLLBACK/BACKOUT TRANSACTION-Statement beginnen. Alle
Datensätze, die während der Transaktion gehalten wurden, werden freigegeben.
Das Natural SQL-Statement ROLLBACK macht alle Datenbankänderungen rückgängig, die seit
Beginn der letzten logischen Transaktion vorgenommen wurden. Logische Transaktionen
können entweder nach dem Beginn einer Sitzung oder nach dem letzten COMMIT-/END
TRANSACTION- oder der ROLLBACK-/BACKOUT TRANSACTION-Statement beginnen. Alle Datensätze,
die während der Transaktion gehalten wurden, werden freigegeben.
Weitere Einzelheiten und die Statement-Syntax finden Sie unter ROLLBACK
(SQL) in der Statements-Dokumentation.
ROLLBACK ist ein Synonym für das Natural-Statement BACKOUT TRANSACTION, das
im Abschnitt Verwendung von nativen Natural
DML-Statements beschrieben ist.
Wenn dieses Kommando von einer Natural Stored Procedure oder einer benutzerdefinierten
Funktion (UDF) aus ausgeführt wird, führt Natural for Db2 die zugrunde liegende
Rollback-Operation aus. Dadurch wird der Aufrufer (Caller) in einen
Must-Rollback-Zustand versetzt. Wenn dieses Kommando von einer
Natural-Fehlerverarbeitung (implizites ROLLBACK) ausgeführt wird, führt
Natural for Db2 die zugrunde liegende Rollback-Operation nicht aus, so dass der Aufrufer
den ursprünglichen Natural-Fehler erhalten kann.
Unter CICS wird das Statement ROLLBACK in einen EXEC CICS
ROLLBACK-Kommando übersetzt. Bei Verwendung des File Servers werden jedoch nur
die seit der letzten Terminal-E/A an der Datenbank vorgenommenen Änderungen rückgängig
gemacht. Dies liegt an der CICS-spezifischen Transaktionsverarbeitung im
Pseudo-Conversational Mode, siehe Natural for Db2 unter CICS.
Unter IMS TM wird das ROLLBACK-Statement in ein IMS-Rollback-Kommando
(ROLB) übersetzt. Es werden jedoch nur die Änderungen an
der Datenbank rückgängig gemacht, die seit der letzten Terminal-E/A vorgenommen wurden.
Dies liegt an der IMS TM-spezifischen Transaktionsverarbeitung, siehe Natural for Db2 unter IMS
TM.
Da alle Cursor am Ende einer logischen Arbeitseinheit geschlossen werden, darf ein
ROLLBACK-Statement nicht innerhalb einer Datenbankschleife stehen,
sondern muss außerhalb einer solchen Schleife oder bei geschachtelten Schleifen nach der
äußersten Schleife stehen.
Wenn ein externes Programm, das in einer anderen Standardprogrammiersprache geschrieben
wurde, von einem Natural-Programm aufgerufen wird, darf dieses externe Programm kein
eigenes ROLLBACK-Kommando enthalten, wenn das
Natural-Programm auch Datenbankaufrufe absetzt. Das aufrufende Natural-Programm muss das
ROLLBACK-Statement für das externe Programm absetzen.
Das Natural SQL SELECT-Statement unterstützt sowohl die cursororientierte
Auswahl, mit der eine beliebige Anzahl an Zeilen abgerufen werden kann, als auch die
nicht-cursororientierte Auswahl (Singleton SELECT), mit der höchstens eine
einzige Zeile abgerufen werden kann.
Alle Einzelheiten und die Statement-Syntax finden Sie unter SELECT (SQL) in der Statements-Dokumentation.
Wie das native DML-Statement FIND wird das cursororientierte
SELECT-Statement verwendet, um eine Reihe von Zeilen (Datensätzen) aus
einer oder mehreren Db2-Tabellen anhand eines Suchkriteriums auszuwählen. Da eine
Datenbankschleife initiiert wird, muss die Schleife durch ein
LOOP-Statement (im Reporting Mode) oder durch ein
END-SELECT-Statement (im Structured Mode) geschlossen werden. Bei dieser
Vorgehensweise verwendet Natural die gleiche Schleifenverarbeitung wie bei einem
FIND-Statement. Außerdem ist keine Cursor-Verwaltung durch das
Anwendungsprogramm erforderlich. Sie wird automatisch von Natural durchgeführt.
Weitere Einzelheiten und die Syntax finden Sie unter Syntax 1 - Cursor-orientierte Auswahl in SELECT (SQL) in der Statements-Dokumentation.
Das Natural SQL-Statement SELECT SINGLE bietet die Funktionalität einer
Nicht-Cursor-Auswahl (Singleton SELECT), d. h. eines
select-expression, der maximal eine Zeile
ohne Verwendung eines Cursors abruft.
Da Db2 das Singleton SELECT-Kommando nur in statischem SQL unterstützt,
wird das Natural-SELECT SINGLE-Statement im dynamischen Modus wie ein
Set-Level-SELECT-Statement ausgeführt, was zu einer Cursor-Operation
führt. Natural prüft jedoch die Anzahl der von Db2 zurückgegebenen Zeilen. Wenn mehr
als eine Zeile ausgewählt wird, wird eine entsprechende Fehlermeldung
zurückgegeben.
Weitere Einzelheiten und die Syntax finden Sie unter Syntax 2 - Nicht cursor-orientierte Auswahl in SELECT (SQL) in der Statements-Dokumentation.
Sowohl das cursororientierte oder Positioned
UPDATE als auch die nicht-cursororientierte oder Searched
UPDATE-Statement wird als Teil von Natural SQL unterstützt.
Beide referenzieren entweder eine Tabelle oder eine Natural-View.
Bei Db2 kann der Name einer Tabelle oder einer Natural-View, die durch ein Searched
UPDATE referenziert werden soll, mit einem
correlation-name versehen werden. Dieser
entspricht nicht der Standard-SQL-Syntaxdefinition und gehört daher zum Natural
Extended Set.
Das Searched UPDATE-Statement muss z.B. zur Aktualisierung eines
Primärschlüsselfeldes verwendet werden, da Db2 die Aktualisierung von Spalten eines
Primärschlüssels mit einem Positioned UPDATE-Statement nicht erlaubt.
Anmerkung
Wenn Sie die Notation SET * verwenden, werden alle Felder der
referenzierten Natural-View zu den Listen FOR UPDATE OF und
SET hinzugefügt. Stellen Sie daher sicher, dass Ihre View nur Felder
enthält, die aktualisiert werden können. Andernfalls wird von Db2 ein negativer SQLCODE
zurückgegeben.
Weitere Einzelheiten und die Syntax finden Sie unter UPDATE (SQL) in der Statements-Dokumentation.
Bei der Verwendung mit Db2 gibt es Einschränkungen und/oder zu beachtende Punkte in Bezug auf die folgenden Natural-Systemvariablen:
Informationen über Einschränkungen und/oder zu beachtende Punkte finden Sie im Abschnitt Datenbank-spezifische Anmerkungen in der entsprechenden Systemvariablen-Dokumentation.
Dieser Abschnitt beschreibt die Multiple Row Processing-Funktionalität für Db2 Datenbanken.
Sie müssen mit Db2 for z/OS Version 8 oder höher arbeiten, um diese Funktionalität nutzen zu können.
Natural for Db2 bietet zwei Arten von Funktionen zur Verarbeitung mehrerer Zeilen:
Diese Funktion hat keinen Einfluss auf die Programmlogik. Obwohl Natural Native DML und Natural SQL DML Klauseln zur Angabe des Multi-Fetch-Faktors bereitstellen, arbeitet das Natural-Programm mit einer Datenbankzeile und aus Sicht des Programms wird nur eine Zeile von der Datenbank empfangen oder an die Datenbank gesendet.
Diese Funktion ist nur mit Natural SQL DML verfügbar und hat erhebliche Auswirkungen
auf die Programmlogik, da sie das Abrufen mehrerer Zeilen aus der Datenbank in den
Programmspeicher durch ein einziges Natural SQL SELECT-Statement in ein
Set von Arrays ermöglicht. Außerdem ist es möglich, mehrere Zeilen aus einem Set von
Arrays mit dem Natural SQL INSERT-Statement in die Datenbank
einzufügen.
Im Folgenden finden Sie Informationen zu den folgenden Themen:
Im Standardmodus liest Natural nicht mehrere Datensätze mit einem einzigen Datenbankaufruf, sondern arbeitet immer im Modus "Ein Datensatz pro Abruf". Diese Art des Betriebs ist zuverlässig und stabil, kann aber einige Zeit in Anspruch nehmen, wenn eine große Anzahl von Datenbanksätzen verarbeitet wird.
Um die Leistung dieser Programme zu verbessern, können Sie die Multi-Fetch-Klausel in
den Natural DML-Statements FIND,
READ oder HISTOGRAM verwenden. Damit können Sie
die Anzahl der pro Datenbankzugriff gelesenen Datensätze angeben.
|
|
FIND
|
|
|
MULTI-FETCH
|
|
ON
|
|
|
READ
|
OFF
|
|||||||
HISTOGRAM
|
OF
multi-fetch-factor
|
wobei multi-fetch-factor entweder eine
Konstante oder eine Variable mit dem Format Integer (I4) ist.
Um die Performance des Natural SQL SELECT-Statements zu erhöhen, können
Sie die WITH ROWSET POSITIONING FOR-Klausel verwenden, um einen
Multi-Fetch-Faktor anzugeben.
|
|
WITH ROWSET POSITIONING FOR
|
|
[:] row_hv |
|
ROWS
|
|
| integer |
Zur Ausführungszeit des Statements prüft die Laufzeit, ob ein Multi-Fetch-Faktor größer als 1 für das Datenbank-Statement angegeben ist.
Ist der multi-fetch-factor
| kleiner oder gleich 1, | wird der Datenbankaufruf im üblichen Modus "Ein Datensatz pro Zugriff" fortgesetzt. |
| größer als 1, | wird der Datenbankaufruf dynamisch vorbereitet, um mehrere Sätze (z.B. 10)
mit einem einzigen Datenbankzugriff in einen Hilfspuffer (Multi-Fetch-Puffer) zu
lesen.
Bei Erfolg wird der erste Datensatz in die zugrunde liegende Datensicht übertragen. Bei der Ausführung der nächsten Schleife wird die Datensicht direkt aus dem Multi-Fetch-Puffer gefüllt, ohne Datenbankzugriff. Nachdem alle Datensätze aus dem Multi-Fetch-Puffer geholt wurden, bewirkt die nächste Schleife, dass der nächste Datensatz aus der Datenbank gelesen wird. Wird die Datenbankschleife beendet (entweder durch End-of-Records, |
Das Programm erhält nicht bei jeder Schleife "frische" Datensätze aus der Datenbank, sondern arbeitet mit Abbildern, die beim letzten Multi-Fetch-Zugriff abgerufen wurden.
Wenn für ein Natural DML READ- oder HISTOGRAM-Statement ein dynamischer Richtungswechsel
(IN DYNAMIC...SEQUENCE) kodiert wird, ist die Multi-Fetch-Funktion
nicht möglich und führt zu einem entsprechenden Syntaxfehler beim Kompilieren.
Die Größe, die eine Datenbankschleife im Multi-Fetch-Puffer belegt, wird nach der folgenden Regel ermittelt:
| header + sqldaheader + columns*(sqlvar+lise) + mf*(udind + sum(collen) + sum(LF(columns) + sum(nullind)) |
| = |
| 32 + 16 + columns*(44+12) + mf*(1 + sum(collen) + sum(LF(column)) + sum(2)) |
Dabei ist:
| header | Länge des Header eines Eintrags im Db2-Multifetch-Puffer, d.h. 32 |
| sqldaheader | Länge des Header einer sqlda, d.h. 16 |
| columns | Anzahl der aufnehmenden Felder einer SQL-Anfrage |
| sqlvar | Länge eines sqlvar, d. h. 44 |
| lise | Länge einer Natrual für Db2 spezifischen sqlvar-Erweiterung |
| mf | Multifetch-Faktor, d.h. die Anzahl der Zeilen, die durch einen Datenbankaufruf geholt werden |
| collen | Länge des aufnehmenden Feldes |
| LF(column) | Größe des Längenfeldes des aufnehmenden Feldes, d. h. 0 für Felder mit fester Länge, 2 für Felder mit variabler Länge und 4 für große Objektspalten (LOBs) |
| nullind | Länge eines Null-Indikators, d. h. 2 |
Der Multi-Fetch-Puffer wird bei der Terminal-Eingabe im Pseudo-Conversional Mode
freigegeben. Daher gibt es keine Größenbeschränkung für den Db2-Multi-Fetch-Puffer
(DB2SIZE6). Der Puffer wird bei Bedarf automatisch vergrößert.
Wenn Multi-Fetch verwendet wird, werden "reale" Datenbankaufrufe nur übermittelt, um einen neuen Satz an Datensätzen zu erhalten.
Die Funktion TEST DBLOG Q wird auch vom Natural for Db2
Multi-Fetch-Handler für jeden Rowset-Fetch aus Db2 und für jeden aus dem
Multi-Fetch-Puffer in den Programmspeicher verschobenen Datensatz aufgerufen. Die
Ereignisse werden durch das Literal MULTI FETCH ... und <BUFF
FETCH ... unterschieden.
10:51:57 ***** NATURAL Test Utilities ***** 2006-01-27 User HGK - DBLOG Trace - Library NDB42 M No R SQL Statement (truncated) CU SN SREF M Typ SQLC/W Program Line LV _ 1 SELECT EMPNO,FIRSTNME,LASTNAM 01 01 0260 D DB2 MF000001 0260 01 _ 2 MULTI FETCH NEX 01 01 0260 D DB2 MF000001 0260 01 _ 3 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 4 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 5 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 6 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 7 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 8 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 9 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 10 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 11 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 12 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 13 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 14 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 15 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 16 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 _ 17 <BUFF FETCH NEX 00 00 0260 D DB2 MF000001 0260 01 Command ===> |
wobei die Spalte No für Folgendes steht:
| 1 | ist ein offener Cursor-Db2-Aufruf. |
| 2 | ist ein "realer" Datenbankaufruf, der eine Reihe von
Datensätzen über Multi-Fetch liest (siehe MULTI FETCH NEX in der
Spalte SQL Statement).
|
| 3-17 | sind keine "realen" Datenbankaufrufe, sondern nur Einträge,
die dokumentieren, dass das Programm diese Sätze aus dem Multi-Fetch-Puffer
erhalten hat (siehe <BUFF FETCH NEX in der Spalte
SQL-Statement).
|
Diese Funktion ermöglicht es Programmen, mehrere Zeilen aus Db2 in Arrays abzurufen.
Diese Funktion ist nur beim SELECT-Statement verfügbar.
Um diese Funktion zu nutzen:
Setzen Sie die Compiler-Option DB2ARRY=ON (unter Verwendung eines OPTIONS-Statements oder des
COMPOPT-Kommandos oder des
Profilparameters CMPO).
Geben Sie eine Liste von empfangenden Arrays in der INTO-Klausel
(siehe into-clause) des SELECT-Statements an.
Geben Sie die Anzahl der Zeilen an, die mit einer einzigen
FETCH-Operation mit der WITH ROWSET
POSITIONING-Klausel
aus der Datenbank abgerufen
werden sollen.
Geben Sie eine Variable an, die die Anzahl der aus der Datenbank abgerufenen
Zeilen über die
ROWS_RETURNED-Klausel
erhält.
DB2ARRY=ON ist
notwendig, um die Angabe von Arrays in der INTO-Klausel zu ermöglichen
(siehe into-clause).
DB2ARRY=ON verhindert auch die Verwendung von Arrays als abgebende oder
aufnehmende Felder bei Db2 CHAR/VARCHAR
/GRAPHIC/VARGRAPHIC-Spalten. Stattdessen müssen
Natural-Skalarfelder mit der entsprechenden Länge verwendet werden.
Jedes in der INTO-Klausel (siehe into-clause) angegebene Array muss
zusammenhängend sein (eine Ausprägung folgt unmittelbar auf eine andere, dies wird von
Db2 erwartet) und muss eindimensional sein. Die Arrays werden von der ersten
Ausprägung (low) bis zur letzten Ausprägung (high) aufgefüllt. Die ersten
Array-Ausprägungen bilden die erste Zeile des erhaltenen Rowset, die zweiten
Array-Ausprägungen bilden die zweite Zeile des erhaltenen Rowset. Die
Array-Ausprägungen des n-ten Index bilden die n-te Zeile, die von Db2 zurückgegeben
wird.
Wenn eine LINDICATOR-Klausel oder INDICATOR-Klausel in der INTO-Klausel
für Arrays verwendet wird, müssen die angegebenen Längenindikatoren oder
Nullindikatoren ebenfalls Arrays sein. Die Anzahl der Ausprägungen von
LINDICATOR- und INDICATOR-Arrays muss gleich oder größer
sein als die Anzahl der Ausprägungen des Master-Arrays.
Die WITH_ROWSET_POSITIONING-Klausel wird verwendet, um die Anzahl der
Zeilen anzugeben, die in einem Verarbeitungszyklus aus der Datenbank abgerufen werden
sollen. Die angegebene Anzahl muss gleich oder kleiner sein als das Minimum der
Ausprägungen aller angegebenen Arrays. Wird eine Variable, nicht eine Konstante,
angegeben, so wird der aktuelle Inhalt der Variablen bei jedem Verarbeitungszyklus
verwendet. Die angegebene Zahl muss größer als 0 und kleiner als
32768 sein.
Die ROWS_RETURNED-Klausel wird verwendet, um eine Variable anzugeben,
die die Anzahl der Zeilen enthält, die während der eigentlichen Fetch-Operation aus
der Datenbank gelesen wurden. Das Format der Variablen muss I4 sein.
Natural-Views: Es ist nicht möglich, Natural-Arrays von Views in der
INTO-Klausel zu verwenden (siehe into-clause), d.h. die Verwendung des
Schlüsselworts VIEW ist nicht möglich.
Der Zweck dieses Merkmals besteht darin, die Anzahl der Datenbank- und
Datenbankschnittstellenaufrufe für die Massenstapelverarbeitung zu reduzieren. Daher
ist es nicht empfehlenswert, diese Art der Programmierung in Online-CICS- oder
IMS-Umgebungen zu verwenden, wenn Terminal-Ein- und -Ausgaben innerhalb offener
Cursorschleifen erfolgen, d.h. der File Server verwendet wird. Erst recht ist es nicht
möglich, nach einer Terminal-E/A ein Positioned
UPDATE- oder Positioned
DELETE-Statement durchzuführen.
Beispiel:
DEFINE DATA LOCAL
01 NAME (A20/1:10)
01 ADDRESS (A100/1:10)
01 DATEOFBIRTH (A10/1:10)
01 SALARY (P4.2/1:10)
01 L$ADDRESS (I2/1:10)
01 ROWS (I4)
01 NUMBER (I4)
01 INDEX (I4)
END-DEFINE
OPTIONS DB2ARRY=ON
ASSIGN NUMBER := 10
SEL.
SELECT NAME, ADDRESS , DATEOFBIRTH, SALARY
INTO :NAME(*), /* <-- ARRAY
:ADDRESS(*) LINDICATOR :L$ADDRESS(*), /* <-- ARRAY
:DATEOFBIRTH(1:10), /* <-- ARRAY
:SALARY(01:10) /* <-- ARRAY
FROM NAT-DEMO
WHERE NAME > ' '
WITH ROWSET POSITIONING FOR :NUMBER ROWS /* <-- ROWS REQ
ROWS_RETURNED :ROWS /* <-- ROWS RET
IF ROWS > 0
FOR INDEX = 1 TO ROWS STEP 1
DISPLAY
INDEX (EM=99) *COUNTER (SEL.) (EM=99) ROWS (EM=99)
NAME(INDEX)
ADDRESS(INDEX) (AL=20)
DATEOFBIRTH(INDEX)
SALARY(INDEX)
END-FOR
END-IF
END-SELECT
END
Diese Funktion ermöglicht es Programmen, mehrere Zeilen aus Arrays in eine Db2-Tabelle einzufügen.
Diese Funktion ist nur mit dem Natural-SQL-INSERT-Statement verfügbar.
Um dieses Merkmal zu nutzen:
Setzen Sie die Compiler-Option DB2ARRY=ON (mit einem OPTIONS-Statement oder dem
COMPOPT-Kommando oder dem
Profilparameter CMPO).
Geben Sie eine Liste von sendenden Arrays in der VALUES-Klausel des Natural-SQL-INSERT-Statement an.
Geben Sie mit der FOR
n ROWS-Klausel die Anzahl
der Zeilen an, die mit einem einzelnen Natural-SQL-INSERT-Statement in die
Datenbank eingefügt werden sollen.
DB2ARRY=ON ist
notwendig, um die Angabe von Arrays in der VALUES-Klausel zu ermöglichen.
DB2ARRY=ON verhindert auch die Verwendung von Arrays als abgebende oder
aufnehmende Felder für Db2 CHAR/VARCHAR
/GRAPHIC/VARGRAPHIC-Spalten. Stattdessen müssen
Natural-Skalarfelder mit der entsprechenden Länge verwendet werden.
Jedes in der VALUES-Klausel angegebene Array muss zusammenhängend sein (eine Ausprägung folgt unmittelbar auf eine andere, dies wird von Db2 erwartet) und muss eindimensional sein. Die Arrays werden von der ersten Ausprägung (niedrig) bis zur letzten Ausprägung (hoch) gelesen. Die ersten Ausprägungen des Arrays bilden die erste in die Datenbank eingefügte Zeile, die zweiten Ausprägungen des Arrays bilden die zweite in die Datenbank eingefügte Zeile. Die Array-Ausprägungen des n-ten Index bilden die n-te in die Datenbank eingefügte Zeile.
Wenn eine LINDICATOR-Klausel oder INDICATOR-Klausel in der VALUES-Klausel für Arrays verwendet wird, müssen
die angegebenen Längenindikatoren oder Nullindikatoren ebenfalls Arrays sein. Die
Anzahl der LINDICATOR- und INDICATOR-Array-Ausprägungen muss
gleich oder größer sein als die Anzahl der Ausprägungen des Master-Array.
Die FOR
n ROWS-Klausel wird verwendet,
um anzugeben, wie viele Zeilen durch eine INSERT-Statement in die Datenbanktabelle eingefügt werden
sollen. Die angegebene Anzahl muss gleich der oder kleiner sein als die Mindestanzahl
der Ausprägungen aller angegebenen Arrays in der VALUES-Klausel. Die angegebene Zahl muss größer als
0 und kleiner als 32768 sein.
Es ist nicht möglich, Natural-Arrays von Views in der VALUES-Klausel zu verwenden, d.h. die
Verwendung des Schlüsselworts VIEW ist nicht möglich.
Aufgrund von Db2-Einschränkungen ist es nicht möglich, Einfügungen mehrerer Zeilen im statischen Modus auszuführen. Daher werden mehrzeilige Einfügungen nicht statisch generiert, sondern immer dynamisch von Natural for Db2 vorbereitet und ausgeführt.
Die statische Generierung mit Natural for Db2 erzeugt ein SQL-Programm in
Assemblersprache, das vom Db2-Precompiler vorkompiliert wird, der wiederum ein
DBRM erzeugt, das für die statische Ausführung erforderlich ist. Der
Db2-Assembler-Precompiler bietet jedoch keine Unterstützung für
Host-Variablen-Arrays. Sie können nur verwendet werden, wenn sie in einer
SQLDA-Struktur angegeben sind, die zur Ausführungszeit erstellt werden muss. Ein
statisches INSERT mit einer VALUES-Klausel für mehrere Zeilen erlaubt jedoch nicht
die Angabe einer SQLDA, sondern nur Host-Variablen-Arrays, die vom
Db2-Assembler-Precompiler nicht unterstützt werden.
Es ist nicht möglich, Natural-Arrays von Views in der INTO-Klausel
zu verwenden (siehe into-clause), d.h. die Verwendung des
Schlüsselworts VIEW ist nicht möglich.
Beispiel:
DEFINE DATA LOCAL
01 NAME (A20/1:10) INIT <'ZILLER1','ZILLER2','ZILLER3','ZILLER4'
,'ZILLER5','ZILLER6','ZILLER7','ZILLER8'
,'ZILLER9','ZILLERA'>
01 ADDRESS (A100/1:10) INIT <'ANGEL STREET 1','ANGEL STREET 2'
,'ANGEL STREET 3','ANGEL STREET 4'
,'ANGEL STREET 5','ANGEL STREET 6'
,'ANGEL STREET 7','ANGEL STREET 8'
,'ANGEL STREET 9','ANGEL STREET 10'>
01 DATENATD (D/1:10) INIT <D'1954-03-27',D'1954-03-27',D'1954-03-27'
,D'1954-03-27',D'1954-03-27',D'1954-03-27'
,D'1954-03-27',D'1954-03-27',D'1954-03-27'
,D'1954-03-27'>
01 SALARY (P4.2/1:10) INIT <1000,2000,3000,4000,5000
,6000,7000,8000,9000,9999>
01 SALARY_N (N4.2/1:10) INIT <1000,2000,3000,4000,5000
,6000,7000,8000,9000,9999>
01 L§ADDRESS (I2/1:10) INIT <14,14,14,14,14,14,14,14,14,15>
01 N§ADDRESS (I2/1:10) INIT <00,00,00,00,00,00,00,00,00,00>
01 ROWS (I4)
01 INDEX (I4)
01 V1 VIEW OF NAT-DEMO_ID
02 NAME
02 ADDRESS (EM=X(20))
02 DATEOFBIRTH
02 SALARY
01 ROWCOUNT (I4)
END-DEFINE
OPTIONS DB2ARRY=ON /* <-- ENABLE DB2 ARRAY
ROWCOUNT := 10
INSERT INTO NAT-DEMO_ID
(NAME,ADDRESS,DATEOFBIRTH,SALARY)
VALUES
(:NAME(*), /* <-- ARRAY
:ADDRESS(*) /* <-- ARRAY
INDICATOR :N§ADDRESS(*) /* <-- ARRAY
LINDICATOR :L§ADDRESS(*), /* <-- ARRAY DB2 VCHAR
:DATENATD(1:10), /* <-- ARRAY NATURAL DATES
:SALARY_N(01:10) /* <-- ARRAY NATURAL NUMERIC
)
FOR :ROWCOUNT ROWS
SELECT * INTO VIEW V1 FROM NAT-DEMO_ID WHERE NAME > 'Z'
DISPLAY V1 /* <-- VERIFY INSERT
END-SELECT
BACKOUT
END
Im Gegensatz zur normalen Natural-Fehlerbehandlung, bei der entweder ein ON ERROR-Statement verwendet wird, um
Ausführungszeitfehler abzufangen, oder eine Standard-Fehlermeldung verarbeitet und die
Programmausführung beendet wird, bietet die erweiterte Fehlerbehandlung von Natural for
Db2 eine anwendungsgesteuerte Reaktion auf den aufgetretenen SQL-Fehler.
Zwei Natural-Subprogramme, NDBERR und NDBNOERR, werden bereitgestellt, um die übliche
Natural-Fehlerbehandlung zu deaktivieren und den aufgetretenen SQL-Fehler auf den
zurückgegebenen SQLCODE zu prüfen. Diese Funktionalität ersetzt die
E-Funktion der DB2SERV-Schnittstelle, die weiterhin zur
Verfügung steht, aber nicht mehr dokumentiert ist.
Weitere Informationen zu den Natural-Subprogrammen, die für Db2 zur Verfügung stehen, finden Sie im Abschnitt Interface-Subprogramme.
Beispiel:
DEFINE DATA LOCAL
01 #SQLCODE (I4)
01 #SQLSTATE (A5)
01 #SQLCA (A136)
01 #DBMS (B1)
END-DEFINE
*
* Ignore error from next statement
*
CALLNAT 'NDBNOERR'
*
* This SQL statement produces an SQL error
*
INSERT INTO SYSIBH-SYSTABLES (CREATOR, NAME, COLCOUNT)
VALUES ('SAG', 'MYTABLE', '3')
*
* Investigate error
*
CALLNAT 'NDBERR' #SQLCODE #SQLSTATE #SQLCA #DBMS
*
IF #DBMS NE 2 /* not DB2
MOVE 3700 TO *ERROR-NR
END-IF
*
DECIDE ON FIRST VALUE OF #SQLCODE
VALUE 0, 100 /* successful execution
IGNORE
VALUE -803 /* duplicate row
/* UPDATE existing record
/*
IGNORE
NONE VALUE
MOVE 3700 TO *ERROR-NR
END-DECIDE
*
END