Mittels dem FINAL Table Statement lassen sich elegant die nach dem einfügen des Datensatzes generierten Werte (Autoincrement, [Row-Change]-Timestamp-Werte) auslesen:
Code:
SELECT * FROM FINAL TABLE (INSERT INTO [meinetable](col1, col2) values('A', 'B'));
Jetzt haben wir schön für die Datenzugriffssicht SQL Prozeduren angelegt, die z.B. für den Insert ein Resultset basierend auf der FINAL Table zurückliefern, gebastelt. (Auf den physischen Tabellen sitzt eine View, d.h. die CRUD-Anweisungen werden auf die View abgesetzt, so auch aus der SQL-Prozedur).

Bei einigen Tabellen habe ich jetzt Probleme bekommen, dass der zweite INSERT über die SQL Prozedur nicht mehr funktionieren wollte:
Code:
SQL-Status: 22011
Vendorencode: -138
Nachricht: [SQL0138] Argument *N der Funktion SUBSTRING oder LEFT ungültig. Ursache  . . . . :  Argument 2 oder Argument 3 der Funktion SUBSTRING oder Argument 2 der Funktion LEFT liegt entweder außerhalb des gültigen Bereichs oder ist ein Ausdruck, der nicht als ganze Zahl bewertet wird. -- Bei der Funktion SUBSTRING gibt Argument 2 die Position des ersten Zeichens des Ergebnisses und Argument 3 die Länge des Ergebnisses an. Argument 2 muss eine gültige Position des ersten Arguments sein. Argument 3 darf die Länge von Argument 1 zwischen Argument 2 und dem Ende der Zeichenfolge nicht überschreiten. -- Bei der Funktion LEFT gibt Argument 2 die Länge des Ergebnisses an. Argument 2 darf die Länge von Argument 1 nicht überschreiten. -- Ist Argument 1 eine Zeichenfolge oder eine Binärzeichenfolge, entspricht ein Zeichen einem Byte; ist Argument 1 eine Grafikzeichenfolge, ein Zeichen oder ein DBCS-Zeichen, entspricht ein Zeichen einem DBCS-Zeichen. -- Ist das Argument *N, ist eines der Argumente ungültig, aber die Nummer des Arguments ist nicht bekannt. Fehlerbeseitigung:  Ist das Argument *N, die vorherigen Nachrichten im Jobprotokoll anzeigen (Befehl DSPJOBLOG) oder F10 (Nachrichten im  Jobprotokoll anzeigen) in dieser Anzeige drücken, um das fehlerhafte Argument zu bestimmen. Ein oder mehrere in der Funktion SUBSTRING oder LEFT angegebene Argumente ändern. Die Skalarfunktion INTEGER kann verwendet werden, um das Argument in ein ganzzahliges Ergebnis umzusetzen. Die Anforderung wiederholen.
Was ich herausgefunden habe, dass es an den Parametern der SQL Prozedur liegen könnte und das die vom System automatisch ermittelten Datentypen der Finaltable vielleicht hier mit den Parametern in die Quere kommen.

Hier die Sourcen der verwendeten Objekte.
Table:
Code:
[CREATE TABLE VAG13P (
 AG13ID   INT GENERATED ALWAYS AS IDENTITY(INCREMENT BY 1) PRIMARY KEY, 
 AG13ID12 INT NOT NULL   with default 0,
 AG13MENG DECIMAL(11, 3) NOT NULL WITH DEFAULT 0,  -- Menge
 AG13RAB  DECIMAL(5, 2) NOT NULL WITH DEFAULT 0,  -- Rabatt 1 
-- Systemfelder
 Created  FOR AG13DATA TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP , 
 Changed  FOR AG13DATE TIMESTAMP NOT NULL GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP ,
 Jobuser  FOR AG13BENA VARCHAR(50) NOT NULL DEFAULT USER ,
 UserEdit FOR AG13BENE VARCHAR(50) NOT NULL DEFAULT USER ,
 WrkStnName FOR AG13WSNAM VARCHAR(50) NOT NULL DEFAULT '' ,
 ClientProgramID FOR AG13CPGMID VarChar(50) NOT NULL DEFAULT '' ,
 ClientApplName FOR AG13CPGM VarChar(50) NOT NULL DEFAULT '',
-- Fremdschlüssel
 FOREIGN KEY(AG13ID12) REFERENCES VAG12P(AG12ID) ON UPDATE RESTRICT ON DELETE CASCADE
)
RCDFMT AG13F1;
View:
Code:
CREATE or REPLACE VIEW mdblib.vVag13P01  AS
 SELECT 
  a.*
  ,CAST(a.CHANGED as VarChar(26)) Version
  
 FROM mdblib.Vag13P a
;
SQL-Procedure für INSERT:
Code:
CREATE PROCEDURE hgwobj.vag13_insert( 
 IN pag13ID12 INTEGER,
 IN pag13meng decimal(11,3),
 IN pag13rab decimal (5,2),
-- Systemfelder
 IN pWRKSTNNAME VARCHAR(50),
 IN pCLIENTPROGRAMID VARCHAR(50),
 IN pCLIENTAPPLNAME VARCHAR(50)
)
LANGUAGE SQL MODIFIES SQL DATA
DYNAMIC RESULT SETS 1
set option COMMIT = *CHG 
BEGIN

DECLARE C1 CURSOR WITH RETURN TO CALLER FOR 
SELECT * FROM FINAL TABLE (
 INSERT INTO vVag13P01
 (
  ag13ID12, ag13meng, ag13rab,
  WRKSTNNAME,  CLIENTPROGRAMID, CLIENTAPPLNAME
 )
 VALUES
 (
  pag13ID12, pag13meng, pag13rab,
  pWRKSTNNAME, pCLIENTPROGRAMID, pCLIENTAPPLNAME
 )
);
-- Cursor öffnen u. zurückgeben
OPEN C1;
SET RESULT SETS WITH RETURN TO CALLER CURSOR C1;
END;
Ich hatte den Fehler bereits in einer anderen Insert-Prozedur behoben, hier musste ich den Datentyp des Parameters von Timestamp(0) auf Timestamp ändern. Im obigen Fall hilft es, den dritten Parameter ( IN pag13rab decimal (5,2)) von decimal(5,2) auf decimal(11,3) zu ändern.

Leider verstehe ich nicht warum. Meine Vermutung ist, dass das Final Table den maximalen Bereich pro Datentyp für alle gleichartigen Spalten festlegt, oder das FINAL Table mit der Art u. Weise wie ich den Cursor zurück liefere nicht zurechtkommen mag.

Bislang hatte ich die Parameter immer 1:1 anhand der Tabellendefinition der Spalten gemacht, oder ist das falsch?
Warum verhält es sich nur manchmal so?