SQL Trigger

[B.Hauser]

Es handelt sich sowohl in der DDS-Datei als auch in der SQL Tabelle um ECHTE Datumsfelder nicht irgendwelche numerischen oder alphanumerischen Werte?

Normalerweise interessiert SQL das Datums-Format nicht, da echte Datumsfelder (im DDS wie in SQL Tabellen) als numerischer Wert (Scaliger No) hinterlegt sind.
Es könnte nur sein, dass die Datumsfelder mit Format irgendwie alphanumerisch im entsprechenden/hinterlegten Format ankommen oder durch das Format ein Feldüberlauf zustande kommt.
Es wäre interessant zu wissen, wie die Datums-Felder im Trigger ankommen (einfach mal mit LPRINTF ins Joblog schreiben).

Was man versuchen könnte:

1. Das Datums-Format im SET OPTION Statement auf ISO stellen: SET OPTION DatFmt = *ISO.
2. Sollte das nicht funktionieren, versuch die Datumsfelder (insbesondere die mit europäischem Format) mit TRY_CAST in ein echtes Datum zu konvertieren
3. Sollte das auch nicht funktionieren, versuche die Daten zunächst in ein alphanumiersches Datum zu konvertieren und danach ebenfalls mit TRY_CAST in ein Echtes Datum

[mk]

Hallo,

Dieter: RPG Trigger könnte ich, will ich aber nicht mehr.
Datenkompost aufräumen bin ich voll deiner Meinung, aber mit der Altanwendung ist das immer so eine Sache ( Zeit ... )

Birgitta: Danke für die Tipps. Aber der Trigger lässt sich nicht erstellen. Ein cast auf die Werte geht syntaktisch zwar aber auch damit lässt der Trigger sich nicht erstellen.

Die Lösung ist leider :
Alle Datumsfelder müssen identisch definiert sein.
Also entweder alle mit DATFMT(*EUR) oder mit DATFMT(*ISO).

Dann kann der Trigger erstellt werden.

Schade
Gruß an *ALL
Michael

[B.Hauser]

was wäre wenn ...
Du für die physische Datei eine SQL View erstellst und dann einen Instead Of Trigger auf die View generierst?

[BenderD]

was wäre wenn ...
Du für die logische Datei eine SQL View erstellst und dann einen Instead Of Trigger auf die View generierst?

... die view muss read only sein (join mit Feldern aus mehreren Tables) und verhindert den update auf die vorhandene Table nicht, der dann dem Trigger egal ist.
D*B

[B.Hauser]

... die view muss read only sein (join mit Feldern aus mehreren Tables) und verhindert den update auf die vorhandene Table nicht, der dann dem Trigger egal ist.
D*B

Wo hast Du denn diese Behauptung her? Instead Of Trigger können nur auf Views angelegt werden und mit Instead Of Trigger können gejointe Tabellen upgedated werden. Soweit sind wir uns wohl einig.
... nur WARUM sollte ein Instead Of Trigger nicht auf einer ungejointen View implementiert werden können.
Und auch das IBM-Beispiel ist für eine ungejointe View:
INSTEAD OF SQL triggers

... und auch Mister ChatCPT kann nichts widersprüchliches finden

[Fuerchau]

Warum kann zur Laufzeit im Trigger nicht mit Set Option Datfmt=*ISO alles vereinheiticht werden?
In deinem Create-Auszug vermisse ich die Set Option Anweisung.

[BenderD]

Wo hast Du denn diese Behauptung her? Instead Of Trigger können nur auf Views angelegt werden und mit Instead Of Trigger können gejointe Tabellen upgedated werden. Soweit sind wir uns wohl einig.
... nur WARUM sollte ein Instead Of Trigger nicht auf einer ungejointen View implementiert werden können.
Und auch das IBM-Beispiel ist für eine ungejointe View:
INSTEAD OF SQL triggers

... und auch Mister ChatCPT kann nichts widersprüchliches finden

... ich beziehe meine Info nicht aus ChatGPT, da ich nicht unter Halluzinationen leide und zu meiner Zeit hätten Kunden das auch nicht honoriert - jeder, wie er will und kann. Der join war nur ein Beispiel für read only, es könnten auch abgeleitete Werte oder Aggregatfunktionen sein.
Wie auch immer, die updates kommen aus einer Altanwendung, die - welche View auch immer - nicht benutzt, sondern die Original Tablelle, die den Trigger nicht feuert.

Mit kollegialen Grüßen

Dieter Bender

[BenderD]

... die Altanwendung arbeitet mit einer DDS LF und merkt nicht, dass darunter eine SQL erstellte Table liegt. Immer noch nicht elegant aber besser als vorher.