Hallo,
ok, ich werde mal die Strukturen der entsprechenden Tabellen liefern.
ja bitte, oder 'ne Accessdatenbank mit den Tabellen und einer ausreichenden (anonymisierten?) Menge an Testdaten.
Meine weitere Überlegung ist, ob man diese Daten nicht in einem Stringrid unterbringen kann. Dann könnte man die Felder dann mit "while-Schleifen" befüllen. Es würde den lokalen Rechner etwas mehr belasten, aber diese Tabelle wird meisten nur einmal die Woche benötigt. Ich muß jedoch erst testen, ob ich ein Stringrid an Fastreport übergeben kann.
Finde ich keine gute Idee. Das, was Du haben möchtest, geht garantiert per
SQL. Das Problem ist momentan eigentlich nur: Es ist noch nicht ganz klar, was Du haben möchtest. Das kann übrigens durchaus daran liegen, dass die Dir gemachten Vorgaben nicht genau genug gemacht wurden und es von daher noch "Spekulationsfreiraum" gibt. Und den kann man mit keiner Programmiersprache der Welt und mit keinem
SQL korrekt abbilden.
Nimm einfach mal schrittweise meine SQLs von oben, bereinige sie ggfls. von Syntaxfehlern und sag uns dann, bis zu welchem Statement noch alle benötigten Daten im Ergebnis enthalten sind, bzw. was im "bestmöglichen" Ergebnis noch zuviel ist. Dann können wir da, ggfls. mit Hilfe von Testdaten, gezielt aufsetzen und, ggfls. mit 'ner Präzisierung der Aufgabenstellung, weiter nach einer Lösung suchen.
Ein (momentan) noch nicht lösbares Problem, lässt sich nicht dadurch lösen, dass man einen anderen Weg geht. Es wird dann nur einen weiteren Weg des Scheiterns geben, das ist nicht zielführend.
Zitat von
Schokohase:
Man muss nicht immer die komplette Aufgabe mit einer Abfrage lösen. Man kann sich die Daten auch in Objekte laden und den Rest der Verarbeitung mit diesen Objekte erledigen. Je komplexer die Aufgabe umso einfacher/übersichtlicher wird so eine getrennte Abarbeitung.
Finde ich nicht, meine praktische Erfahrung ist eher gegenteilig. Präzise und gute SQLs / Datenbankabfragen, ersparen einem ggfls. tausende von Programmierzeilen. Zumal dann, wenn es "nur" darum geht, einen Report zu schreiben/auszugeben. Ich persönlich erwarte dann, dass das auszugebende Ergebnis in einer Abfrage vorliegt und ich nur noch für die Übergabe der Daten an den Report sorgen muss. (Aber das ist sicherlich auch Geschmacksache.)
Zitat von
Schokohase:
Und diese Anforderung schreit gerade danach.
Nein, die Anforderung schreit nach Präzisierung, ohne die wird auch jede Programmierung scheitern (auch wenn das jetzt sehr hart klingen mag.)
Zitat von
p80286:
Nichts für ungut, aber mir ist eher unklar was der TE eigentlich will (so wie ich es verstanden habe muß <177 nicht berechnet werden, darf aber, warum dann die Unterscheidung? "Arbeitserleichterung"?)
Genau da liegt der Hase im Pfeffer, meine Versuche mit Union all oder ohne Union all ... resultieren eben genau aus diesem "entschiedenen sowohl als auch oder eventuell vielleicht ja oder doch nicht". Der TE sollte hier nochmal beim "Auftraggeber" nachfragen, was der denn nun möchte und dort eine klare Entscheidung einfordern. Ein: "man kann was ausgeben / berechnen oder auch nicht" darf in der Anforderung nicht mehr enthalten lassen.
@Luckner
Fordere bitte eine präzise Vorgabe dessen, was der Report enthalten soll und was nicht, ein und lasse dich bitte nicht mit etwas abspeisen, was nicht klar mit ja oder nein zu beantworten ist.
Oder anders formuliert: Die Vorgabe muss in einem Entscheidungsbaum abzubilden sein, es darf dort keine Stelle geben, an der ein weitere Verlauf über unterschiedliche Wege möglich ist.