SELECT mit mehrfachen records - moeglich ?

[FrankBKK]

Hallo zusammen,

ich bin mir nicht sicher ob man das ueberhaupt so loesen kann, aber jeder Hilfe ist willkommen,
ich stehe da total auf dem Schlauch ...

Fuer einen Report soll eine Query erzeugt werden um einige Etiketten zu drucken -
die Anzahl der Etiketten pro Artikel richtet sich nach dem Wert im Datenbank-Feld MENGE des jewiligen Artikels.

Beispiel:
Artikel / Preis / Menge
4711 - 1.50 - 4
4712 - 2.20 - 8
4713 - 1.30 - 2

Fuer Produkt 4711 sollen also 4 Etiketten gedruckt werden,
fuer Produkt 4712 sollen dann 8 Etiketten gedruckt werden,
fuer Produkt 4713 sollen noch 2 Etiketten gedruckt werden,

Die SQL-Abfrage sollte also in etwa folgende Ergebnismenge liefern:
Produkt / Preis
4711 - 1.50
4711 - 1.50
4711 - 1.50
4711 - 1.50
4712 - 2.20
4712 - 2.20
4712 - 2.20
4712 - 2.20
4712 - 2.20
4712 - 2.20
4712 - 2.20
4712 - 2.20
4713 - 1.30
4713 - 1.30

d.h. irgendwie muessen die einzelnen Datensaetze MENGE-mal geclont werden -
ich komm einfach nicht dahinter wie man das machen kann ... :wall:

Hat jemand ne Idee wie man das in eine SELECT - Anweisung fasst ?

[mkinzler]

Da wirst du um eine SP nicht herumkommen

[Hansa]

Zitat:

Zitat von mkinzler

..um eine SP nicht herumkommen

Hört sich so an, als müsste man die vermeiden. 8) Weitere Stichworte sind :

SQL-Code:

for

SQL-Code:

count

Das dann im Delphi-Programm auswerten.

[omata]

Die dann so aussehen könnte...

SQL-Code:

CREATE PROCEDURE MAKEOUTOUT ()
RETURNS (
  Spalte1 Integer,
  Spalte2 Integer,
  Spalte3 Varchar(500),
  Anzahl  Integer 
)
AS
DECLARE VARIABLE i INTEGER;
BEGIN 
  FOR SELECT Spalte1, Spalte2, Spalte3, Anzahl
      FROM tabelle
      INTO Spalte1, Spalte2, Spalte3, Anzahl DO 
  BEGIN 
    i = 0;
    WHILE (i < Anzahl) DO BEGIN  
      SUSPEND; 
      i = i + 1;
    END
  END 
END

Edit: Hier noch ein Hack, mit dem das auch einfach mit SQL geht.
Dies setzt allerdings eine Tabelle mit Zahlen voraus.

SQL-Code:

SELECT *
FROM tabelle, anzahlen
WHERE zahl <= anzahl

Hier wird also eine neue Tabelle benötigt, die immer alle Zahlen von 1 bis zur maximal größten Anzahl in "tabelle" enthält. Wenn du da also einfach alle Zahlen von 1 bis 1000 einmal in solch eine Tabelle einträgst, sollte das vielleicht reichen.
Oder du erstellst deine SQL-Abfrage dynamisch, dann kannst du diese Anzahl-Tabelle auch produzieren...

SQL-Code:

SELECT *
FROM tabelle, (SELECT 1 zahl FROM tabelle
               UNION 
               SELECT 2 FROM tabelle
               UNION
               SELECT 3 FROM tabelle) anzahlen
WHERE zahl <= anzahl

Dies hat den Vorteil gegenüber einer SP, dass du bei Spaltenänderungen an deiner Tabelle die neuen Informationen schneller in deinem Report zur Verfügung hast. Bei einer SP musst du da erst alle neuen Spalten durchschleppen.

Dies würde unter MSSQL mit einer Benutzerdefinierten Funktion noch viel geschickter gehen, aber das ist eine andere Geschichte...

War nur so eine Idee...

[mkinzler]

Sttat SP könnte man auch einen EXECUTE BLOCK verwenden.

[Jelly]

Zitat:

Zitat von FrankBKK

d.h. irgendwie muessen die einzelnen Datensaetze MENGE-mal geclont werden -
ich komm einfach nicht dahinter wie man das machen kann ... :wall:

Was willst du damit machen? Warum brauchst du die Records jeweils x mal in der Ergebnismenge. Wäre es nicht sinnvoller, ein normales Select abzufeuern, und dann Record für Record die Menge jeweils auszuwerten und damit zu machen was du möchtest(z.B. x Etiketten ausdrucken)

[Hansa]

Zitat:

Zitat von Jelly

(z.B. x Etiketten ausdrucken)

Dazu ist das COUNT da. Hiermit das x ermitteln. SP wird nicht mal gebraucht.

SQL-Code:

SELECT COUNT (BLUBB) FROM TABLEX WHERE BLA INTO :ETIKETTEN

Den Wert im Dataset auslesen und im Programm x-mal drucken. Basta. :zwinker:

[omata]

Um dem Ganzen mal eine andere Denkrichtung zu geben...

Man kann Etiketten auch z.B. mit Microsoft Word erstellen. Dort ist es einfacher die Datenquelle zu manipulieren. Und da wird dann so ein Clonen benötigt.

[Elvis]

Zitat:

Zitat von mkinzler

Da wirst du um eine SP nicht herumkommen

Nicht unbedingt, nicht seit Firebird 1.5 oder 2.0.

Einfach das hier mal als Query absetzen:

SQL-Code:

execute block
returns
(
  Name       VarChar(30),
  RelationID Integer,
  RowNum     Integer
)
as
begin
  for SELECT Rdb$Relation_ID,
             trim(Rdb$Relation_Name)
      FROM   Rdb$Relations
      WHERE  Rdb$System_Flag = 1
      into :RelationID,
           :Name do
  begin
    RowNum = 1;
    while(RowNum <= RelationID) do
    begin
      suspend;
      RowNum = RowNum + 1;
    end
  end
end;

edit: lol, gerade erst gesehen...

Zitat:

Zitat von mkinzler

Sttat SP könnte man auch einen EXECUTE BLOCK verwenden.

[omata]

Folgendes ist da trotzdem unverändert...

hier: EXECUTE BLOCK = SP

Zitat:

Zitat von omata

... dass du bei Spaltenänderungen an deiner Tabelle die neuen Informationen schneller in deinem Report zur Verfügung hast. Bei einer SP musst du da erst alle neuen Spalten durchschleppen.

[Elvis]

Zitat:

Zitat von omata

Folgendes ist da trotzdem unverändert...

hier: EXECUTE BLOCK = SP

Zitat:

Zitat von omata

... dass du bei Spaltenänderungen an deiner Tabelle die neuen Informationen schneller in deinem Report zur Verfügung hast. Bei einer SP musst du da erst alle neuen Spalten durchschleppen.

Ja, da fehlt mir in Firebird irgendwie die Möglichkeit, Sprocs nach der ersten Ergebnismenge auszuführen.

Ich hoffte das sowas ginge (wie pipeln fnctions in Oracle), aber issnich:

SQL-Code:

select t.*, s.RowNum
from Tabelle t,
     GeSequencials(1, t.Anzahl) s

[omata]

Ja genau, deshalb auch die Anspielung auf...

Zitat:

Zitat von omata

Dies würde unter MSSQL mit einer Benutzerdefinierten Funktion noch viel geschickter gehen, aber das ist eine andere Geschichte...

[FrankBKK]

Hallo zusammen -

vielen Dank fuer die verschiedenen Loesungsansaetze.

Ich denke, dass eine SP am meisten Sinn macht - schon aus
Performance-Gruenden. Ist etwas komplizierter, aber was solls.

Die Sache mit dem ExecuteBlock war mir neu - das mus ich
mir mal genauer ansehen.

Eine eigene Idee ist mir beim Lesen der Beitraege noch durch
den Kopf geschossen - nur mal so als Diskussionsgrundlage:
SELECT mit selbst-referenziertem JOIN
hmm, da muss ich mal dran rumprobieren ...

[omata]

Zitat:

Zitat von FrankBKK

SELECT mit selbst-referenziertem JOIN
hmm, da muss ich mal dran rumprobieren ...

Die Idee hatte ich auch, aber dafür müssen in der Tabelle immer alle Anzahlen lükenlos von 1 bis max Anzahl vorhanden sein. Ist das immer gewährleistet?