Announcement

Collapse
No announcement yet.

Wie formulier' ich's

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wie formulier' ich's

    Hallo ihr da draußen!

    Erstmal ein herzliches Dankeschön an all die Helfer an den <br>
    Bildschirmen, ich glaube, dies ist das produktivste Forum, das mir <br>
    bis jetzt unter die Links gekommen ist. DANKE! <br>
    Das wollte ich einfach mal loswerden. <br>

    Natürlich hab ich aber auch noch ein kleines Problem: <br>

    Ich möchte in einer SQL-Abfrage Werte aus mehreren Tabellen darstellen, <br>
    was ja auch weiter nicht schwer ist. Nun möchte ich einen weiteren <br>
    Wert einfügen, der aus der Summe einiger Werte aus einer weiteren <br>
    Tabelle gebildet wird. Um das etwas klarer zu machen: Ich habe in <br>
    einer Tabelle mehrere Datensätze a1, a2, a3... Zu diesen Datensätzen <br>
    gibt es in einer weiteren Tabelle nun die Datensätze <br>
    a1_1, a1_2, a1_3,...,a2_1, a2_2... Ich möchte aus a1_1 .. a1_n <br>
    einen Wert summieren, der dann als zusätzliches Feld von a1 <br>
    dargestellt wird (und natürlich geht das mit a2, a3,... so weiter). <br>
    Ich hab's erstmal mit <p>
    SELECT a.nr, a.irgendwas, (SELECT SUM(b.wert) FROM tab_b b)
    FROM tab_a <p>
    versucht, aber dann erhalte ich natürlich für jede Zeile den gleichen <br>
    Wert, der auch noch falsch ist, weil ja alle Werte aus b summiert <br>
    werden. Der Versuch mit <p>
    SELECT a.nr, a.irgendwas, (SELECT SUM(b.wert) FROM tab_b b, tab_a a <br> WHERE (b.Zanr = a.nr)) <br>
    FROM tab_a <p>
    wobei b.Zanr den Wert von a.nr enthalten soll, zu dem dieser Datensatz <br>
    aus b gehört. Dabei erhalte ich aber gar keinen Wert für die Summe. <br>
    Wie muß ich denn da die SQL-Abfrage formulieren? <p>
    Ein anderes Problem in dem Zusammenhang ist, das der zu summierende <br>
    Wert vom Typ TIME ist, der bei mir für SUM aber immer einen Typ-Mismatch <br>
    Fehler ausgibt. (Die Abfragen oben habe ich mit integer ausprobiert, <br>
    im Endeffekt sollen es aber TIME-Werte sein, die summiert werden). <p>

  • #2
    Hallo,

    der wichtigste Teile der Frage fehlt: Welche Datenbank wird verwendet (LOCAL SQL oder SQL-Datenbank)

    Comment


    • #3
      Es geht um Paradox-Tabellen, auf die dementsprechend mit Local-SQL zugegriffen werden soll/muß. <br>
      (Trotzdem wär's schön, auch einen Weg für SQL zu wissen - wenn das unabhängig vom SQL-Server zu beantworten wäre

      Comment


      • #4
        Hallo,

        bei einer Paradox-Datenbank stehen nur die Leistungsmerkmale von LOCAL SQL zur Verfügung. Angenommen, es werden 2 Testtabellen erstellt:

        TAB_A.DB: <br>
        ID = AutoInc <br>
        Wert1 = INTEGER <br>
        Kommentar = VARCHAR <br>

        TAB_B.DB: <br>
        IDTAB_B = AutoInc <br>
        ID = INTEGER <br>
        Wert2 = INTEGER <br>
        Zeit = TIME <br>

        Beide Tabellen sind über referenzielle Integrität verbunden, somit ist TAB_B.ID der Fremdschlüssel zum Primärschlüssel TAB_A.ID. Über einen JOIN lassen sich beide Tabellen so verbinden, das die Summe aller Werte aus Wert2 für eine bestimmte ID ermittelt werden kann:
        <pre>
        SELECT a.Wert1, a.Kommentar, SUM(b.Wert2)
        FROM TAB_A a JOIN TAB_B b ON a.ID = b.ID
        GROUP BY a.Wert1, a.Kommentar
        </pre>
        Bei dem TIME-Wert wird es kompliziert, da in der BDE-Hilfedatei LOCALSQL.HLP der folgende Satz steht: "<i>SUM läßt sich nur auf numerische Werte anwenden. Wenn nicht-numerische Werte verarbeitet werden sollen, müssen Sie die betreffende Spalte mit Hilfe der Funktion CAST zuerst in einen numerischen Typ konvertieren.</i>".

        Daher wird mit einem doppelten CAST gearbeitet, um den TIME-Wert zuerst in eine Zeichenkette und dann in einen NUMERIC-Wert umzuwandeln. Und NUMERIC kann SUM zusammenzählen:
        <pre>
        SELECT a.Wert1, a.Kommentar, SUM(CAST(CAST(b.Zeit AS CHAR(10)) AS NUMERIC))
        FROM TAB_A a JOIN TAB_B b ON a.ID = b.ID
        GROUP BY a.Wert1, a.Kommentar
        </pre>
        Leider hat die Sache einen kleinen Haken - bei der Typumwandlung treten "Rundungsfehler" auf, so das die Summer aller Zeitwerte nicht auf die Sekunde genau ist. Wenn jedoch nur mit Stunden bzw. Minuten gerechnet werden muss, dürfte die Genauigkeit ausreichen.
        &#10

        Comment

        Working...
        X