BenderD
07-03-17, 13:27
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.
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.
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.
siehe 2.
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!
Bislang keine Probleme gehabt - zählt "Version" zu den reservierten Schlüsselwörtern? Wäre RowVersion besser?
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
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.
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.
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.
siehe 2.
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!
Bislang keine Probleme gehabt - zählt "Version" zu den reservierten Schlüsselwörtern? Wäre RowVersion besser?
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