Moin, moin,

habe folgende prinzipielle Datensatzstruktur

ID; Number; String
1...435......abc
2...456......def
3...674......ghi

Mein Problem:

brauche ein Statement, das den concatierten Stringwert der Stringfelder zurückgibt
also in obigen Fall 'abcdefghi'. Jedenfalls bin ich da im Moment sehr einfallslos...


Grüße // Martin

Moin mschaefer!

Ich denke, dass du die ganze Tabelle ein mal durchlaufen und dabei den String selber zusammenbauen musst. Etwa so:

zusammenfalten · markieren

Delphi-Quellcode:

  ...

  Label1.Caption := '';

  ADOTable1.First;

  while not ADOTable1.Eof do
  begin
    Label1.Caption := Label1.Caption + ADOTable1.FieldValues['string'];
    ADOTable1.Next;
  end;

  ...

An einer SQL-Lösung bin ich auch interessiert, obwohl ich nicht glaube, dass es so eine einfache SQL-Lösung für dein Problem gibt (bin kein SQL-Profi).

Viele Grüße
Markus

Moin Markus,

ja das wäre die leidigste Variante, aber sicherlich funktioniert die.
Wenn alle SQL-Stricke reißen, dann muß ich mich doch nochmal mit einer
Stored-Procedure beschäftigen. Aber ich meine da müßte es doch noch
etwas mit UNION geben. Erstmla wieder lesen...

Grüße // Martin

Hallo mschaefer,

UNION hilft dir hier nicht weiter. Mit UNION kannst du mehrere verschiedene Abfragen in eine Datenmenge zusammenfassen, sofern die Struktur der einzelnen Ergebnisse identisch sind. Du erhälst aber dann eine Menge von Datensätzen. Du willst ja eine Zusammenfassung einer Spalte einer Tabelle. Das geht dann tatsächlich so, wie Markus es beschrieben hat oder mit der von dir angesprochenen StoredProcedure.

Moin, moin

mit dem Segen der Vulkanier werde ich dann an meine SP setzen (nach dem Teetrinken)
und dann melde ich mich wieder !

Grüße / Martin

Da ich selbst noch kein Firebird-Crack bin hab' ich's kurz getestet.
Die Domain/Variablen namen dürften selbsterklärend sein.

markieren

SQL-Code:

CREATE TABLE MASTER
(
    ID PRIMKEY /* PRIMKEY = INTEGER NOT NULL */,
    NAME SHORTSTRING /* SHORTSTRING = VARCHAR(255) NOT NULL */
);

markieren

SQL-Code:

CREATE TABLE DETAIL
(
    ID PRIMKEY /* PRIMKEY = INTEGER NOT NULL */,
    MASTER FOREIGNKEY /* FOREIGNKEY = INTEGER NOT NULL */,
    SEQUENCE SEQUENCIAL /* SEQUENCIAL = INTEGER NOT NULL */,
    TEXT SHORTSTRING /* SHORTSTRING = VARCHAR(255) NOT NULL */
);

zusammenfalten · markieren

SQL-Code:

create procedure ZusammenFriemelei
returns
(
  ID integer
 ,MASTER varchar( 255)
 ,TEXT varchar(4000)
)
as
declare variable DetailText varchar(255);
begin
  for SELECT Id
            ,Name
      FROM Master m
      ORDER BY m.Name
      INTO :Id, :Master do
  begin
    Text = '';

    for SELECT Text
        FROM Detail d
        where d.Master = :Id
        ORDER BY d.Sequence
        INTO :DetailText do
    begin
      if (DetailText is not null) then
        Text = Text || DetailText;
    end

    suspend;
  end
end

Hallo Robert,

das haut mir doch glatt den Sonntagstee um! Klasse! Selbst an den NULl Fall hast Du gedacht.
Soweit war ich noch gar nicht. Du könntest in meinem Fall sogar noch den Order by weglassen
um etwas Zeit zu sparen. Sonst ist das die Lösung die ich angepasst auf meine Daten einbauen
werden. Damit bedanke ich mich, eigentlich habe ich jetzt sogar ein etwas schlechtes Gewissen
den die SP hätte ich doch auch doch auch selbst gemacht !

Viele Grüße in die Runde // Martin

Du musst bei solchen SPs (also Prozeduren mit Ergebnismenge) aufpassen.
Sie verbrauchen ein Vielfaches an Ressourcen, da die einzelnen Ergibnismengen zwischen verschiedenen Prozessen hin-und hergeschubst werden.
Da man in Firebird keine Funktionen schreiben kann ist es aber die einzige Lösung, die mir einfällt.
(Eine externe UDF halte ich in dem Fall für Blödsinn, die müsste sich ja die Daten über die externe API holen )
In Ora hätte ich die Spalte mit einer Funktion beschreiben lassen, der hätte ich einfach die ID des Mastersatzes übergeben. Aber man kann ja nicht alles haben.

Zitat:

Soweit war ich noch gar nicht. Du könntest in meinem Fall sogar noch den Order by weglassen
um etwas Zeit zu sparen.

Du kannst in einem DBMS niemals davon ausgehen, dass deine Daten in der Reihenfolge abgefragt werden, in der sie in der Tabelle stehen. Genauso werden sie nicht immer in der Reihenfolge in die Tabelle geschrieben in der du die Inserts abgestzt hast. (Die DB wird sich immer die "passendste" Lücke suchen)
Ein Ascending Index auf Sequence und die Abfrage wird nur unwesentlich langsamer werden. (wenn sie überhaupt langsamer wird).
Da du sowieso einen Unique key auf Master & Sequence hast sollte es also keine Performance-problemchen mit einem "ORDER BY Sequence" geben.

Hallo Robert,

hört sich sinnig an. Ja Deine Einschätzung zu UDF´s teile ich. Meiner Erfahrung nach sind die nur für mit Daten des aktuellen Datensatzes zu gebrauchen und Datensatzwechsel sind daher nur in SP machbar.
Aber ich denke lieber eine SP als das manuelle Durchlaufen. Das System läuft bei mir im WLAN und da ist Datenmenge über die Verbindung doch wieder relevant. Danke für Deine wirklich fundirte Hilfe!

Grüße // Martin