mehrere Spalten in Ergebnismenge

[Hansa]

Was nützt es mich, die EXE nicht ändern zu müssen, dafür aber die View bzw. die DB ? Oder andersrum gefragt : wie kann ich die View parametrisieren ? Geht IMHO nicht. Ich kann ja wohl schlecht am 1.1.2013 eine neue View anlegen, weil es dann auch Daten für 2013 gibt.

[Furtbichler]

Nun ja, es nützt etwas, wenn der Kunde oder wer auch immer die View anpassen kann, ohne die EXE ändern zu müssen, weil aus Sicht der EXE die View ja immer noch die gleichen Daten (von der Struktur her) liefert. Aber wenn Du natürlich mit deiner One Man Show keinen Bedarf an solchen Konzepten hast, dann bringt Dir das natürlich nichts. Ebensowenig scheinst Du Interesse an klaren Strukturen und Paradigmentrennung zu haben, was nicht weiter schlimm ist, da Du ja alleine arbeitest.

Und stell Dir mal vor, Du bietest deinen Kunden irgendwann doch mal einen Reportgenerator an und kannst dann -boah ey- auf eben diese View zurückgreifen, weil, verflixt, die etwas komplexere Query gerade nicht zur Hand ist. Und auch würde dann gelten: Wenn sich die Struktur der Datenbank ändert (bei Dir natürlich nicht, aber bei Amateuren kommt so etwas schon mal vor), dann kann man die Sicht auf die Daten (daher könnte der Name 'View' kommen) ändern, ohne -wie gesagt- die EXE'n, Report-Templates, EXCEL-Dateien, Web-Anwendungen usw. anfassen zu müssen. Das alles hast Du natürlich nicht: Du hast nur diese eine EXE und den Compiler immer dabei.

Aber das sind ja nur hypothetische Überlegungen, die für Profis deines Kalibers eh alle nicht zutreffen.

[Bummi]

Ich schließe mich meinem Vorredner inhaltlich an (ohne den persönlichen Aspekt).
Die Sicht kannst Du möglicherweise nicht ändern (ich weiß nicht ob Deine DB Functiontables kennt), aber Du kannst Sie so formulieren dass sie auch in Jahren noch gültig ist, indem Du das Jahr in die Ausgabe mit aufnimmst und bei der Summierung entsprechend berücksichtigst, wobei eine entsprechende Mitaufnahme von ID_ART in Deinem Fall auch Sinn machen sollte.

[Hansa]

Zitat von Furtbichler:

Aber das sind ja nur hypothetische Überlegungen, die für Profis deines Kalibers eh alle nicht zutreffen.

Stimmt, ja. So was kann allerdings nur ein Dummschwätzer sagen, der am grünen Tisch sitzt und sich theoretische Überlegungen Jenseits der Praxis ausdenkt

Allgemein gültig muss es jedoch sein. Werde den View wohl in SP umbauen. Und @furtbichler: ich könnte auch die betreffende Tabellen umbauen.

[mkinzler]

Zitat:

Weiss ich auch nicht (sollte eine 0 sein). Ich meinte, man könnte das subselect wegkürzen. Hab kein FB zum testen, aber es sollte doch einfacher gehen, oder?

Er hat die Aggegatsfunktion hier nicht wollen, deshalb habe ich es mit der Derived Table implementiert.

[Furtbichler]

Moin,
das lese ich zwar nicht heraus, aber offensichtlich würde es auch einfacher gehen (dein Beispiel ist dafür aber sehr verständlich).

[Hansa]

Zitat von Furtbichler:

Aber das sind ja nur hypothetische Überlegungen, die für Profis deines Kalibers eh alle nicht zutreffen.

Haha, Nach der Überheblichkeit kommt meist der tiefe Fall oder zumindest die Erleuchtung. Siehe hier :

Zitat von Furtbichler:

Weiss ich auch nicht (sollte eine 0 sein). Ich meinte, man könnte das subselect wegkürzen. Hab kein FB zum testen, aber es sollte doch einfacher gehen, oder?

Wenn ich das so im nachhinein lese :

Es geht mit einem Wort mehr in meinem SQl in Beitrag #5. Das wars. Kein Subselect, kein View, kein IIF (obwohl bei mir das CASE wohl die selbe Wirkung hat). Jedenfalls reichen 15 Zeilen als normales SQL Statement grundsätzlich aus. Habe da dann noch ein paar Parameter eingebaut und die where-Bedingung verfeinert und fertig. Ist auch bereits in Delphi teilweise eingebaut bzw. umgesetzt.

Ausdrücklicher Dank geht an mkinzler und DeddyH.

[Furtbichler]

Zitat von Hansa:

[
Haha, Nach der Überheblichkeit kommt meist der tiefe Fall oder zumindest die Erleuchtung.

Schon bemerkt? Wenn ich tief falle, musst Du hoch fliegen, damit wir uns in der Mitte treffen.

Soviel zum Niveauunterschied.


Und damit es nicht bierernst wird:

[Hansa]

Ich habe jetzt hier folgendes im SELECT einer SP stehen:

Code:

    CASE JAHR
      WHEN :VERGLJAHR THEN JAHR
      ELSE 0
    END AS VERGLJAHROUT,
    CASE JAHR WHEN :VERGLJAHR THEN
    SUM (CASE MONAT WHEN 1 THEN UMSATZ
         ELSE 0
         END)
    ELSE 0
    END AS MON1,
    CASE JAHR WHEN :VERGLJAHR THEN
    SUM (CASE MONAT WHEN 2 THEN  UMSATZ
         ELSE 0
         END)
    ELSE 0
    END AS MON2

Das Ganze soll jetzt für 2 Jahre und dann insgesamt 24 Monate funktionieren. Es geht zwar jetzt so auch, aber an allen Ecken frage ich ja den Parameter für das jewilige Jahr ab. Kann man das kürzer hinkriegen ? Also ungefähr so :

Code:

    CASE JAHR
      WHEN :VERGLJAHR THEN /*  hier 12 Monate von VerglJahr behandeln
      WHEN :AUSGJAHR THEN /*   12 Monate von AusgJahr... 
      ELSE 0
    END AS ??

[Hansa]

Das ist jetzt alles soweit erledigt. Allerdings noch eine Frage :

Wie werden die angezeigten Felder gruppiert ? Mit dem hier :

Code:

returns (
    artnr integer,
    mon01 decimal(15,2),
    mon02 decimal(15,2),
    mon03 decimal(15,2),
...
    altmon01 decimal(15,2),
    altmon02 decimal(15,2),
    altmon03 decimal(15,2),
...
INTO :ARTNR,
  :MON01,:MON02,:MON03,...ALTMON01,:ALTMON02,:ALTMON03...

wird mir zumindest in IBEXPERT folgendes angezeigt :

von links nach rechts : altmon1,altmon2,mon01,mon02,altmon3, usw.