Hallo Herr Fürchau, danke für die Antwort.

Was ich herausgefunden habe:
  • Egal ob physische Tabelle oder View, der zweite Insert schlägt fehl
  • Egal ob ich im SELECT x FINAL TABLE die Spalten angebe oder mit JOKER-Zeichen arbeite, der zweite Insert schlägt fehl
  • Im Jobprotokoll beschwert sich das System über den o.g. Fehler für die Spalte WSNAM (also eines der Systemfelder am Ende der Tabelle)
    Code:
    SQL-Status: 22011
Vendorencode: -138
Nachricht: [SQL0138] Argument *N der Funktion SUBSTRING oder LEFT ungültig.
    Entferne ich diese Systemfelder (Ersteller, Erstellzeit etc.) aus der SQL Prozedur u. dem darin enthaltenen Spalten auch beim Insert, beanstandet mir die Runtime zuletzt einen Fehler mit der Spalte "Rabattwert"

Code:
SQL-Status: 22023
Vendorencode: -406
Nachricht: [SQL0406] Umsetzungsfehler bei der Zuordnung zu Spalte RABATTWERT. Ursache  . . . . :  Bei dem Versuch, Spalte RABATTWERT mit einer Anweisung INSERT, UPDATE, ALTER TABLE oder REFRESH TABLE einen Wert zuzuordnen, ist ein Umsetzungsfehler der Art 6 aufgetreten. Wurde eine Vorkompilierung durchgeführt, ist der Fehler aufgetreten, als eine numerische Konstante in dieselben Attribute wie Spalte RABATTWERT umgesetzt werden sollte. Mögliche Fehlerarten sind: -- Fehlerart 1 - Überlauf. -- Fehlerart 2 - Gleitkommaüberlauf. -- Fehlerart 3 - Gleitkommaunterlauf. -- Fehlerart 4 - Gleitkommaumsetzungsfehler. -- Fehlerart 5 - Ungenaues Ergebnis. -- Fehlerart 6 - Ungültige numerische Daten. -- Fehlerart 7 - Ungültige DBCS-Daten. Fehlerbeseitigung:  Die Anweisung so ändern, dass der Ergebniswert in Spalte RABATTWERT passt und gültig ist, oder die Tabelle oder Sicht unter Angabe einer neuen Art oder einer neuen Länge für Spalte RABATTWERT erneut erstellen, so dass der Ergebniswert zugeordnet werden kann. Technische Beschreibung  . . . . . . . :  Während der Vorkompilierung wurde versucht, numerische Konstanten in INSERT- und UPDATE-Anweisungen in die Attribute der Zielspalte umzusetzen. Dies hätte eine Leistungssteigerung beim Aufrufen des Programms zur Folge.
Das Problem liegt also nicht an den Systemfeldern die es anfangs im Joblog beanstandet, sondern eigentlich an dem numerischen Rabattfeld mit Decimal(5,2). Wenn ich diesen Prozedurparameter mit IN pRabattWert decimal (11,3) definiere, funktioniert es. Am Select des Final-Table Statements dürfte es nicht liegen, da ich hier mit
Code:
SELECT RabattId, Menge, cast(RabattWert as decimal(5,2)) RabattWert... FROM FINAL TABLE (
keinen Erfolg hatte.

Bislang hatte ich folgende Datentypen verwendet:
  • Int(eger) für ganze Zahlen
  • Decimal(x,y) für Fließkommazahlen
  • [N]VarChar(x) für Texte

Ist Decimal hier evtl. nicht ideal und führt zu Konvertierungsproblemen gerade auch mit C# im Nachgang?

PS: Ich hatte die Feldnamen im Zuge der Überarbeitung angepasst u. die Suffixe des Tabellennamens für die Spalten weggelassen!!!