VARPG und dynamisches SQL

[Fuerchau]

Da muss ich dann doch Dieter zustimmen und halte das Konzept für generell falsch (wer immer auch so eine Anforderung stellt).
VARPG ist dafür der absolut falsche Ansatz, da sich sowas tatsächlich nur mit CLI lösen läßt.
Embedded dynamisches SQL arbeitet immer noch mit fest definierten Cursorn.
Wenn also ein Cursor geöffnet ist, kann der selbe Name nicht nochmal verwendet werden, man muss den Cursor dann erst schließen um mit einem anderen Select neu Daten zu lesen.

Um das ganze abzukürzen:
Ein solches Konzept gehört in die Tonne gedrückt, da man alle Vorteile des SQL's (Join's, CTE's, u.v.m.) überhaupt nicht nutzen kann.
Ausserdem produziert man nicht unerheblichen Overhead mit vollkommen unnötigen Konvertierungen.

SQL's gehören genau dahin, wo sie gebraucht werden und nicht in irgendwelchen Call-Ebenen versteckt.

[caltmann]

Alles klar!
Danke für die Infos/Meinung.
SQL wurde ja auch nicht wegen SQL selbst gewählt,
sondern eigentlich nur um das Satzformat-Problem zu umgehen.
Falls da an CLI also kein Weg vorbeiführt, so muss es
dann wohl so sein....(macht mich klarerweise
auch nicht glücklich, ich werde aber damit leben [müssen])
Danke + lg
Chris

[BenderD]

... naja, SQL kann neben Fug auch jeden Unfug und freilich könnte man sowas im View Layer vorgaukeln und über instead Trigger sogar update fähig machen, aber Details dazu rücke ich allenfalls auf der Kappensitzung der Gesellschaft für Informatik raus, damit ich solchen Quatsch (in Worten Quatsch) nicht noch ungewollt unterstütze.

D*B


Da muss ich dann doch Dieter zustimmen und halte das Konzept für generell falsch (wer immer auch so eine Anforderung stellt).
VARPG ist dafür der absolut falsche Ansatz, da sich sowas tatsächlich nur mit CLI lösen läßt.
Embedded dynamisches SQL arbeitet immer noch mit fest definierten Cursorn.
Wenn also ein Cursor geöffnet ist, kann der selbe Name nicht nochmal verwendet werden, man muss den Cursor dann erst schließen um mit einem anderen Select neu Daten zu lesen.

Um das ganze abzukürzen:
Ein solches Konzept gehört in die Tonne gedrückt, da man alle Vorteile des SQL's (Join's, CTE's, u.v.m.) überhaupt nicht nutzen kann.
Ausserdem produziert man nicht unerheblichen Overhead mit vollkommen unnötigen Konvertierungen.

SQL's gehören genau dahin, wo sie gebraucht werden und nicht in irgendwelchen Call-Ebenen versteckt.

[caltmann]

;-) ist klar.
Naja, wir werden diese Thematik wohl auslagern
(lies: in einer anderen Sprache realisieren) müssen.
Danke nochmal für eure Tipps/Meinungen!

lg
Chris