Office: Listbox per QDF füllen

Hallo!

Es wird in díesem Thread wohl niemand ernsthaft behaupten können, daß die Variante mit QD.SQL = ".." mit anschließender Verwendung als Recordsource "unsauber" ist, nur weil er eine andere Auffassung vertritt.
Oder doch?

Wolfgang

 

Wenn ich
Code:

mit dem direkten Weg
Code:

vergleiche, wüsste ich für die üblichen Fälle nicht welchen Vorteil es hat, den 'Umweg' über das Qdf zu nehmen.
Ich würde diese Variante jedoch weniger als unsauber, sondern
eher als überflüssig (=unsauber???*wink.gif*) bezeichnen wollen.

Wenn z.B. Formular und Bericht auf die selbe Datenherkunft eingestellt werden sollen,
kann diese Variante schon nützlich sein.

 

Hallo!

@Wolfgang:

Kannst du mir bitte die Stelle zeigen, in der ich behaupte, dass die Verwendung von Recordsource unsauber ist? Oder die Stelle wo ich behaupte, du schreibst unsauberen Code?

Ich zitiere noch einmal den Textteil mit der "Sauberkeit"

Meist ist das, was man selbst verwendet, verständlicher als anderes.
Das muss aber nicht zwangsweise immer die "sauberere" Lösung sein.

In diesen Text hineinzuinterpretieren, dass ich behaupte, du schreibst unsauberen Code, hätte ich nicht erwartet.
Die obige Aussage ist allgemein gemeint und passt z. B. auch gut zu meinem eigenen Code. Ich schreibe oft Code, bei dem ich der Meinung bin, dass er klar strukturiert ist. Trotzdem überarbeite ich solchen Code nicht zu selten zu einem späteren Zeitpunkt, wenn ich bemerke, dass er vielleicht nicht so verständlich oder fehlerunanfällig ist, wie ich anfangs dachte, um den Code für spätere Wiederverwendung "sauberer" (verständlicher, weniger fehleranfällig, besser testbar, ...) zu gestalten.

Ich finde es schade, dass man nicht sachlich (gerne auch mit persönlichem Einsatz) über Vorteile von der einen oder anderen Variante diskutieren kann, sondern ein "Angriff auf die dynamische SQL-Text-Zusammensetzungsvariante" als persönlicher Angriff interpretiert wird und damit eine weitere sachliche Diskussion abgedreht wird.

/EDIT:
Wenn wir schon beim Thema "sauberer" Code sind, vielleicht 2 passende URLs dazu:
Clean Code – Wikipedia
Clean Code Developer

mfg
Josef

 

\@Josef
@Marsu

Einer sagt saubererer Code.
Ein anderer sagt überflüssiger Code.

Manche betrachten dieses Forum offenbar als Tribunal.
Wenn jemand etwas schreibt, was dem einen oder anderen nicht gefällt so wird er abqualifiziert. Ohne geringste Ahnung ob des Hintergrundes warum jemand etwas so und nicht anders codiert. Hier sich nicht die Intentionen des jeweiligen Autors entscheidend, sondern es wird ein Satz herausgepickt und zerpflückt, weil man meint, es besser zu wissen.

Abgesehen von jener handvoll Leuten, die dieses Forum entscheidend prägen, gibt es auch noch andere, die etwas zu sagen haben. Denen sollte man auch Raum geben ohne sie gleich zu diskreditieren.
Ich selbst schreibe professionelle Anwendungen seit Access 2.0 ganz ohne irgendeine Forumsunterstützung . Die gab es damals noch gar nicht. Und auch nicht als Autodiakt.
Wenn ich eine bestimmte Vorgangsweise favorisiere, so werde ich dafür meine Gründe haben. Zu meinen, daß daran etwas überflüssig sei, zeugt von einer gewissen Engstirnigkeit.
Wenn hier etwas vorgeschlagen wird, welches in ein bestimmtes Anwendungskonzept paßt, habe ich keine Scheu es zu verwenden. Schließlich lernt man nie aus. Aber ich wehre mich gegen sorgfältigst ausgefeiltes Besserwissen, welches vordergründig harmlos versucht, den Verfasser in ein schiefes Licht zu rücken.

Wolfgang

 

Meine Güte Wolfgang,

"Tribunal ..." - fühle dich doch nicht immer gleich persönlich angegriffen und bleibe einfach mal beim Thema. Du musst nicht jedes Mal hier ein kleines Scharmützel beginnen und die Threads mit deinen Empfindlichkeiten beglücken, nur weil dir die Ausdrucksweise nicht passt oder du etwas zwischen den Zeilen liest. Dafür gibt es PNs - alles andere ist streng genommen off topic (auch mein Sermon hier, aber ich habe keine Lust auf DIN A4 lange Stellungnahmen von dir, das hatte ich schon, brauche ich nicht mehr).

"Besserwissen" ist übrigens auch nicht gerade nett ausgedrückt, aber ich denke, dass sich Josef und Kollegen deshalb auch nicht gleich in die Hose machen.

 

Wolfgang,
hier werden Vor-/Nachteile von Programmiermethoden diskutiert und manchmal
auch vor einem bestimmten Hintergrund begründet qualifiziert.
Es geht nie um die Qualifizierung von Personen!(!!!)
Somit sollte man auch Aussagen zu seinem geposteten Code nie persöhnlich nehmen!

Das beziehe ich mal auf meinen Post in Beitrag #32
Wenn ich schreibe

dann bin ich neugierig, ob mir jemand einen Vorteil aufzeigen kann, den ich noch nicht erkannt habe
und rege andere gleichzeitig damit an ihren Code zu reflektieren.

Sicherlich, aber dann wäre es nett, diese Gründe auch darzustellen, damit andere
deinen Gedanken folgen und evtl. ihrerseits davon profitieren können.

BTW: Bitte auch die Emoticons beachten, die kennzeichnen, dass etwas scherzhaft, ironisch ... gemeint ist.

 

Hallo Marsu65!

Ich wills versuchen:

Die relativ komplexe Abfrage mit handgestrickten Where- und Having-Klauseln und anschließenden Speichern dient
- zur Anzeige von Suchergebnissen
- zur Ermittlung von Datensatzreihen, die für Erfassungsformulare dienen, da die Abfrage selbst nicht aktualisierbar ist (sie stellt gleichsam das Auswahlkriterium für zu bearbeitende Datensätze dar)
- als Datenquelle für zwei Berichte.

Sie wird einmal ermittelt, gespeichert und anschließend viermal verwendet.
Eine jeweils neuerliche Ermittlung halte ich für überflüssig.

Wolfgang

 

Na guck,
das deckt sich doch mit

Und alles ist gut. *Smilie