Insert mit SQL Prozedur liefert Resultset mittels Final Table

[Fuerchau]

Oder mal eine Fehlermeldung an IBM abgeben. Auch die IBM soll ja nicht ganz fehlerfrei arbeiten.

[BenderD]

... ich finde irgendwie kein close auf den Cursor. Declare cursor ist eine rein deklarative Compiler Anweisung, beim open wird dann ein impliziter prepare mit gemacht. Das müsste eigentlich noch ein warning (cursor state not valid) beim zweiten Aufruf bringen.
Darüber hinaus gibt es noch ein paar Dinge, die ich nicht verstehe:
- warum erfolgt die Rückgabe per ResultSet?
- warum erfolgt die Rückgabe nicht über in/out parameter? (alle Felder hin, die generierten Werte kommen als out verändert zurück)
- weshalb der cast auf den Timestamp?
- warum heißt der changed Timestamp Version (als Version taugt der nicht, das kann schief gehen!)?
- generell sollte man condition handler für error vorsehen, sonst düst man unversehens raus.

Dieter Bender

[Fuerchau]

Der Timestamp-Cast ist wohl dem ODBC-Zugriff (C#) geschuldet, da dieser ggf. damit nicht zurechtkommt.
Für den CLose ist doch eigentlich der Aufrufer zuständig, wobei dieser ja vom Cursor-Namen nichts kennt.
Aber ohne Final Table scheints ja zu funktionieren.

[Gutmann]

Hallo Herr Bender,
Hallo Herr Fürchau,

danke für die Antwort. Aktuell habe ich ein Ticket bei IBM zu dem Thema laufen. Mal sehen was zu dem Thema mit dem Final Table herauskommt.

1. ... ich finde irgendwie kein close auf den Cursor. Declare cursor ist eine rein deklarative Compiler Anweisung, beim open wird dann ein impliziter prepare mit gemacht. Das müsste eigentlich noch ein warning (cursor state not valid) beim zweiten Aufruf bringen.
Darüber hinaus gibt es noch ein paar Dinge, die ich nicht verstehe:
- 2. warum erfolgt die Rückgabe per ResultSet?
- 3. warum erfolgt die Rückgabe nicht über in/out parameter? (alle Felder hin, die generierten Werte kommen als out verändert zurück)
- 4. weshalb der cast auf den Timestamp?
- 5. warum heißt der changed Timestamp Version (als Version taugt der nicht, das kann schief gehen!)?
- 6. generell sollte man condition handler für error vorsehen, sonst düst man unversehens raus.

Dieter Bender

1. Das Resultset soll an die aufrufende Instanz (C# Command-Objekt bzw. ILERPG) zurückgeliefert werden können. Ich habe es eben nochmals gestestet, wenn ich den CLOSE Aufrufe kommt kein Resultset zurück. Ein Warning habe ich keines in den Nachrichten bzw. Joblog gesehen.
2. Eine Rückgabe per Result ist meiner Meinung nach flexibler, d.h. ich liefere einen Satz zurück u. nicht mittels Versorgung von 50 INOUT Parametern. Das wäre im C# der Tot eine solche Parameterlatte in einer Schleife in eine DataTable zu pumpen bzw. bei Verwendung von typisierten DataSets (In-Memory-Datenbank mit Relation) arbeitet man mit TableAdaptern - diese benötigen ein Resultset u. können keine Satzweise Verarbeitung.
3. siehe 2.
4. Wie Herr Fürchau angemerkt hat, ist leider der ODBC Treiber nicht in der Lage TIMESTAMP(6) darzustellen, sondern schafft maximal TIMESTAMP(0) - zumindest in der Standardeinstellung. Durch den CAST auf einen String erzeuge ich quasi eine "Pseudo-GUID" -mit Gültigkeit für den einen Datensatz - bitte nicht falsch Verstehen, es ist kein Primary Key!
5. Bislang keine Probleme gehabt - zählt "Version" zu den reservierten Schlüsselwörtern? Wäre RowVersion besser?
6. Thema Exceptionhandling ist hier an dieser Stelle nicht gewollt - die Aufrufende Instanz der Logikschicht (AS400 über den SQLCode u. C# bekommt bei Fehler eine OdbcException) soll je nach Fehler reagieren.

[Fuerchau]

Statt ODBC-Treiber sollte man den OLEDB-Treiber (IBMDASQL) verwenden.
Dann braucht man auch keine ODBC-Registrierung.
Zur Vereinfachung der Konfiguration kann man eine "xxx.UDL"-Datei erstellen. Diese lässt sich per Doppelklick auch einfach konfigurieren.
In einer OLEDB-Connection gebe ich die Konfiguration einfach so an:

ConnectionString = "File Name=c:\test.udl"

[BenderD]

Hallo Herr Bender,
Hallo Herr Fürchau,

danke für die Antwort. Aktuell habe ich ein Ticket bei IBM zu dem Thema laufen. Mal sehen was zu dem Thema mit dem Final Table herauskommt.

1. Das Resultset soll an die aufrufende Instanz (C# Command-Objekt bzw. ILERPG) zurückgeliefert werden können. Ich habe es eben nochmals gestestet, wenn ich den CLOSE Aufrufe kommt kein Resultset zurück. Ein Warning habe ich keines in den Nachrichten bzw. Joblog gesehen.
2. Eine Rückgabe per Result ist meiner Meinung nach flexibler, d.h. ich liefere einen Satz zurück u. nicht mittels Versorgung von 50 INOUT Parametern. Das wäre im C# der Tot eine solche Parameterlatte in einer Schleife in eine DataTable zu pumpen bzw. bei Verwendung von typisierten DataSets (In-Memory-Datenbank mit Relation) arbeitet man mit TableAdaptern - diese benötigen ein Resultset u. können keine Satzweise Verarbeitung.
3. siehe 2.
4. Wie Herr Fürchau angemerkt hat, ist leider der ODBC Treiber nicht in der Lage TIMESTAMP(6) darzustellen, sondern schafft maximal TIMESTAMP(0) - zumindest in der Standardeinstellung. Durch den CAST auf einen String erzeuge ich quasi eine "Pseudo-GUID" -mit Gültigkeit für den einen Datensatz - bitte nicht falsch Verstehen, es ist kein Primary Key!
5. Bislang keine Probleme gehabt - zählt "Version" zu den reservierten Schlüsselwörtern? Wäre RowVersion besser?
6. Thema Exceptionhandling ist hier an dieser Stelle nicht gewollt - die Aufrufende Instanz der Logikschicht (AS400 über den SQLCode u. C# bekommt bei Fehler eine OdbcException) soll je nach Fehler reagieren.

ad 1.: das ResultSet muss bei der Rückgabe geöffnet sein. Die Frage bezog sich darauf, dass es vor dem erneuten open closed sein muss (also am Anfang close!)
ad 2/3.: Das ist halt die Crux mit den stored Procedures, da gibt es im handling der verschiedenen SQL Dialekte Unterschiede, die halt zu Randproblemen führen können.
ad 4.: der insert in die View mit dem cast ist schon ein wenig schwindelig...
ad 5.: VERSION ist in der Tat reserviertes Wort (könnte man aber rausmaskieren mit :"VERSION", was ich meinte war, dass Timestamps nicht eindeutig sind.
ad 6.: Ohne Continue handler kriegt man innerhalb der Procedure nichts mehr mit und düst direkt raus. Das ist gerade im verteilten Umfeld nicht so toll, da sollte man zumindest das ein oder andere noch protokolieren...

D*B

[Gutmann]

IBM hat ein PTF SI64636 erstellt damit der Fehler mit dem Final-TABLE Statement behoben ist. Testen werden wir das ganze allerdings erst zum Jahreswechsel.