ADOQuery berechnetes Feld

[p80286]

Zitat:

Zitat von jobo (Beitrag 1434207)

Create Statement mit Constraints

Das könnte bei Access problematisch sein, aber die Eigenschaften der Tabellen liefern schöne Bilder.

Gruß
K-H

[Luckner]

Hallo,

ok, ich werde mal die Strukturen der entsprechenden Tabellen liefern. 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.

Schöne Feiertage noch.

Gruß, Luckner

[Schokohase]

Theoretisch kann man alles als Daten-Quelle für FastReport verwenden.

Man legt ein

Delphi-Quellcode:

TfrxUserDataSet

an und verdrahtet dort den Zugriff auf die Daten. Das war es schon.

Zu der Abfrage selber:

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.

Und diese Anforderung schreit gerade danach.

[p80286]

Zitat:

Zitat von Schokohase (Beitrag 1434217)

Theoretisch kann man alles als Daten-Quelle für FastReport verwenden.

Man legt ein

Delphi-Quellcode:

TfrxUserDataSet

an und verdrahtet dort den Zugriff auf die Daten. Das war es schon.

Zu der Abfrage selber:

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.

Und diese Anforderung schreit gerade danach.

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"?)

Gruß
K-H

[Delphi.Narium]

Zitat:

Zitat von Luckner (Beitrag 1434216)

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.

Zitat:

Zitat von Luckner (Beitrag 1434216)

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:

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:

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:

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.

[p80286]

Zitat:

Zitat von Delphi.Narium (Beitrag 1434228)

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.

Mmm....ich habe mindestens ein Drittel meiner Arbeitszeit damit verbracht, chaotische unpräzise Formulierungen
in halbwegs logische Anforderungen zu überführen.

Und ich habe nie herausbekommen ob Dummheit, Ignoranz oder was auch immer der Grund für diese WischiWaschi-Anforderungen war.

Gruß
K-H

[Delphi.Narium]

Zitat:

Zitat von p80286 (Beitrag 1434241)

Zitat:

Zitat von Delphi.Narium (Beitrag 1434228)

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.

Mmm....ich habe mindestens ein Drittel meiner Arbeitszeit damit verbracht, chaotische unpräzise Formulierungen
in halbwegs logische Anforderungen zu überführen.

Und ich habe nie herausbekommen ob Dummheit, Ignoranz oder was auch immer der Grund für diese WischiWaschi-Anforderungen war.

Gruß
K-H

Ich weiß, das kenne ich zur Genüge.
Oft hat es geholfen so penetrant nachzufragen, dass der Aufwand, eine präzise Vorgabe zu machen geringer war, als sich immer und immer wieder um die Beantwortung der Fragen der "blöden" Programmierer kümmern zu müssen.

Es ist ja nix dagegen einzuwenden, wenn man aus dem Chaos etwas macht, was dann logisch klingt und umsetzbar zu sein scheint. Aber damit bin ich dann immer zur anfordernden Person gegangen und habe gefragt: "Willst Du das?" Und habe sie dann darauf festgenagelt mit ja oder nein zu antworten oder eben die Anforderung zu präzisieren. Meist klappte das, wenn auch selten beim ersten Versuch.

[p80286]

Zitat:

Zitat von Delphi.Narium (Beitrag 1434257)

Es ist ja nix dagegen einzuwenden, wenn man aus dem Chaos etwas macht, was dann logisch klingt und umsetzbar zu sein scheint. Aber damit bin ich dann immer zur anfordernden Person gegangen und habe gefragt: "Willst Du das?" Und habe sie dann darauf festgenagelt mit ja oder nein zu antworten oder eben die Anforderung zu präzisieren. Meist klappte das, wenn auch selten beim ersten Versuch.

:thumb:

Gruß
K-H

[Luckner]

Hallo,
also ich versuche es jetzt mein Problem verständlich zu machen.
Die Tabellen der Datenbank sind in MS-Access. Die Hauptanwendung ebenfalls. Die zusätzliche Tools in Delphi. Als Zugriff auf die Datenbank benutze ich ADOQuery.
In diesem Fall werden 3 Tabellen angesprochen.
1. [Lieferanten-Stamm], mit [Lieferanten-Stamm].LieferantNr und [Lieferanten-Stamm].LieferantName
2. [Material-Stamm], mit den Feldern: [Material-Stamm].[Mat-Nr], [Material-Stamm].Bezeichnung, [Material-Stamm].[Lieferant-Nr], [Material-Stamm].aktuell.(Wenn [Material-Stamm].aktuell = -1 dann Materialmenge muss beobachtet werden).
3. Materialrollen, mit den Feldern: Materialrollen.[Mat-Nr], Materialrollen.Nr (Rollennummer), Materialrollen.[Arb-Breite] (nur wichtig, wenn > 179mm) , Materialrollen.lfm(wichtig wenn lfm = 0) , Materialrollen.DatumAb, usw.

Aufgabe: Suche alle Materialrollen eines Lieferanten (das selectiere ich mir schon vorab und bekommen entsprechend: TEditLieferantNr.Text := [Lieferanten-Stamm].LieferantNr. Bis dahin kein Problem.

dann nur noch Select über 2 Tabellen.
Aufgabe: Suche alle Materialrollen von [Material-Stamm].[Lieferant-Nr] = TEditLieferantNr.Text, dessen [Material-Stamm].aktuell = -1, weil nur dieses Material interessant ist. Hier werden die [Material-Stamm].[Mat-Nr] selectiert.

Suche alle Materialrollen.Nr zu dieser Materialrollen.[Mat-Nr] = [Material-Stamm].[Mat-Nr], die eine Materialrollen.[Arb-Breite] > 179 mm haben und Materialrollen.DatumAb = NULL ist. (nur dann sind ensprechende Materialrollen auf Lager. Aus allen Rollen des Materials, die selectiert wurden, berechne die qm (BESTAND).

Wenn Materialrollen.[Arb-Breite] <= 179 mm haben und Materialrollen.DatumAb = NULL ist, solche Rollen sollen nicht berücksichtigt. Dieses Material muss ebenfalls in der Tabelle angezeigt werden mit BESTAND = 0. Ebenfalls wenn es keine Rollen mit Materialrollen.DatumAb = NULL gibt, dann muß das Material ebenfalls in der Tabelle aufgelistet sein mit BESTAND = 0;

Natürlich haben diese Tabellen noch andere Felder, die spielen hier jedoch keine Rolle.

Der Sinn des Ganzen ist, dass man bestimmte Materialsorten eines Lieferanten im Auge behält und rechzeitig bestellt, weil der Lieferant möglicherweise nicht innerhalb einer bestimmten Frist liefern kann und entsprechend auch anderes Material des Lieferanten gleich mitbestellt, falls deren Mengen zu gering erscheinen.

Ich hoffe, jetzt ist es verständlich, ansonsten liefere ich weitere Antworten.

Gruß, Luckner