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