VARPG und dynamisches SQL

[caltmann]

Konkretes Beispiel habe ich leider keines, im Prinzip sind
die Daten aber ganz "normale" SQL-Tabellen.
Die Vorgabe ist aber, mit nur EINEM Programm, ALLE Tabellen
auslesen zu können. D.h. dieses eine Lese-Programm wird - wenn man so will - von unterschiedlichsten Bildschirmen aufgerufen und soll dann den durch den Select Cursor
gefundenen Satz als Datenwurst zurückliefern, unabhängig
von der Anzahl der Felder, Datentypen und Aufbau.
Es wird dann ein String mit maximaler Länge im Programm
vorgesehen, um die Auswertung des Datenstrings kümmert
sich dann ein anderes Programm.
Kann gut sein, dass sich sowas mit SQL gar nicht realisieren läßt, das bin ich eben gerade am erforschen.
Nachdem andere Entwicklungsumgebungen aber Datawindows/-Areas/-Grids o.Ä. unterstützen, lassen sich dann hier vielleicht
so in einer Schleife die Spalten durch Konvertieren zusammen"stringen", damit der VARPG damit gefüttert werden kann.
Also VARPG-GUI sendet "Select X from Y... " an das
"Connector"-DLL, dies schickt dann die gewünschten Spalten
in einer Wurst zurück, und das VARPG-GUI, welches den Aufbau ja kennt (aber eben erst zur Laufzeit, da es für unterschiedliche Tabellen verwendet wird), analysiert den
String und stellt die Daten am Bildschirm dar.
Mit OVRDBF, LVLCHK(NO) und einer Dummy-Datei geht das ohne SQL bereits sehr gut.
Voraussetzung ist hier aber, dass der
Satzformatname zum Kompilationszeitpunkt bekannt ist.
Nachdem dies bei einzelnen Tabellen nicht vorausgesetzt
werden kann, der Satzformatname aber nicht dynamisch
sonder fix sein muss, war unser Ansatz, es über den SQL-Weg
zu versuchen. Für andere Vorschläge sind wir natürlich
gerne offen.

Ich Hoffe es hilft zum besseren Verständnis.
lg
Chris

[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