[SQL] Datensatz kopieren

[Nersgatt]

Hallo,

ich stehe im Moment etwas auf dem Schlauch.
Ich möchte einen Datensatz mit leichten Änderungen kopieren. Dabei möchte gern alle Felder, bis auf 2 bestimmte Felder eins zu eins kopieren. Und das auch, wenn in Zukunft evtl. mal Felder dazukommen.

In SQL könnte ich ja schreiben:

SQL-Code:

INSERT INTO TABELLE (ID, NAME, VORNAME) SELECT 4 AS ID, NAME, VORNAME FROM TABELLE WHERE ID = 3;

Das produziert eine Kopie von Datensatz 3 und weist die ID 4 zu.
Wenn nun aber in Zukunft noch das Feld BERUF hinzu kommt, möchte ich mein SQL-Statement nicht ändern müssen. Wie geht man sowas an?

Leider kann ich im SELECT den * nur benutzen, wenn ich sonst nichts mit reinschreibe. Sonst hätte ich so eine Idee gehabt:

SQL-Code:

INSERT INTO TABELLE SELECT 4 AS ID, * FROM TABELLE WHERE ID = 3;

Geht aber nicht.

Tipps?

Danke!
Jens

[Relicted]

Ich glaube das ist nicht möglich. Ich wunder mich aber gerade, dass das "4 as ID" funktioniert. Ich kannte es bisher nur dass man direkt den Wert also hier nur "4" hinschreiben würde.

Gruß
Reli

[Nersgatt]

Zitat:

Zitat von Relicted

Ich wunder mich aber gerade, dass das "4 as ID" funktioniert. Ich kannte es bisher nur dass man direkt den Wert also hier nur "4" hinschreiben würde.

Mit "AS ID" weise ich dem ja nur einen Namen zu. Vielleicht könnte ich es mir sparen, habe ich mir aber mal so angewöhnt.

Wenn ich schreibe

SQL-Code:

SELECT 4 FROM RDB$DATABASE

dann nennt Firebird die Spalter "F_1".
Wenn ich schreibe

SQL-Code:

SELECT 4 AS ID FROM RDB$DATABASE

dann heißt die Spalte halt "ID".

Gruß,
Jens

[nahpets]

Hallo,

kenne Firebird nicht.

Bei Oracle oder SQL-Server täte ich ins Dictionary schauen und mir dort aus den Einträgen zur Laufzeit das passende Statement bauen, mit Ausnahme der Spalten, bei denen ich selbst was ändern möchte.

Unter SQL-Server könnte das ungefähr so aussehen:

SQL-Code:

select 'insert into tabelle (ID '
union all
select ' ,' + column_name from information_schema.columns where table_name like 'tabelle' and column_name <> 'ID'
union all
select ') select 4 as ID'
union all
select ',' + column_name from information_schema.columns where table_name like 'tabelle' and column_name <> 'ID'
union all
select 'from tabelle where id = 3'

Wenn Du Dir nun das Ergebnis dieses SQL nimmst, solltest Du das Insert-Statement erhalten, das Du wünschst.

SQL-Code:

insert into tabelle (ID
 ,name
 ,vorname
 ,beruf
) select 4 as ID
,name
,vorname
,beruf
from tabelle where id = 3

Und wenn Du neue Spalten in die Tabelle einfügst, so ändert sich das Ergebnis der ersten Abfrage um die entsprechenden Spalten und passt sich somit an Dein geändertes Datenmodell an.

Unter Oracle haben wir mal ein System gebaut, dass permanenten Änderungen des Datenmodells unterworfen war und ist. Diese Routinen sind nun seit etwa 5 Jahren im Einsatz und mussten bisher nicht einmal angepasst werden.

[Relicted]

Ja bei Abfragen ist das ja auch i.O. aber bei "Insert Selects" überflüssig, da es da auf die Reihenfolge ankommt wie du die Spalten angibst.

Gruß
reli

[Hansa]

Wie wärs denn mit sowas :

Delphi-Quellcode:

Dataset2 := Dataset1; // alle Felder zunächst mal kopieren
// einzelne Felder bearbeiten
Dataset2.Post;

[Nersgatt]

Zitat:

Zitat von nahpets

Bei Oracle oder SQL-Server täte ich ins Dictionary schauen und mir dort aus den Einträgen zur Laufzeit das passende Statement bauen, mit Ausnahme der Spalten, bei denen ich selbst was ändern möchte.

Danke, so oder ähnlich kann ich es in Firebird auch umsetzen. Ich mag halt dieses SQL-Zusammen-Gebastel nicht sonderlich, aber ich glaube hier führt kein Weg daran vorbei. Immer noch besser, als bei jedem neuen Feld daran denken zu müssen, auch diese Routine anzupassen.
Bis vor einiger Zeit habe ich 4GL programmiert, dort konnte man sowas einfach mit dem Befehl BUFFER-COPY lösen. Naja, alles hat sein Vor- und Nachteile.

Gruß,
Jens

[Nersgatt]

Zitat:

Zitat von Hansa

Wie wärs denn mit sowas :

Delphi-Quellcode:

Dataset2 := Dataset1; // alle Felder zunächst mal kopieren
// einzelne Felder bearbeiten
Dataset2.Post;

Siehe oben: Delphi.NET mit Firebird.NET Provider :mrgreen:

Gruß,
Jens

[Hansa]

Soll das heißen, bei .NET gibts in Delphi kein TDataset oder ähnliches mehr ? :shock:

[Nersgatt]

Zitat:

Zitat von Hansa

Soll das heißen, bei .NET gibts in Delphi kein TDataset oder ähnliches mehr ? :shock:

Es gibt in .NET ein Dataset, das hat aber mit dem TDataSet nicht viel zu tun. Ist ein ganz anderes Konzept.

Gruß,
Jens

[nahpets]

Hallo Jens,

Zitat:

Zitat von Nersgatt

Danke, so oder ähnlich kann ich es in Firebird auch umsetzen. Ich mag halt dieses SQL-Zusammen-Gebastel nicht sonderlich, aber ich glaube hier führt kein Weg daran vorbei.

ist 'ne Gewohnheitssache, man muss hier zwar erstmal ein bisserl mehr Gehirnschmalz reinstecken, aber es macht die Sache hoch flexibel und, wenn's einmal läuft, sehr pflegeleicht. Da können die Kunden, die Analytiker, die Gesetzgeber noch soviele neue Werte fordern oder vorhandene ändern: Wenn's lüpt, dann lüpt's. ;-)

Nochmal zu dem oben genannten Beispiel von mir:

Der Kunde, für den wir da tätig waren, hatte mehrere Systeme, die sich mindestens vierteljährlich änderten. Es war ein Datenaustausch notwendig zwischen einem halben Dutzend Systemen mit ähnlicher Änderungsrate. Das war zuerst in C++ geschrieben und jede Änderung musse in die Bibliothek übernommen werden, damit die Programme eine einheitliche Schnittstelle hatten. Bibliotheken mussten also in Quartalsversioenn gepflegt werden, die Programme jeweils mit den Bibliotheken kompiliert und den entsprechenden Versionen vorliegen. Wir sind Wahnsinnig geworden, weil man da einfach nicht mehr mithalten kann. Also haben wir gesagt: Die Datenbank ist Oracle (das einzig Konstante in dem System), wir bauen ein Package, dass den Job übernimmt und von den Programmen nur aufgerufen wird mit einer Angabe, zu welchem Jahr, Quartal und Version Daten zu übernehmen sind. Es gibt eine Konfigurationstabelle, in der die Versionen verwaltet werden und das läuft, auch wenn die SQL's dahinter zum Teil extrem komplext geworden sind, da ja bei der Übernahme auch noch die Constrains zu beachten sind...
Aber der Aufwand hat sich gelohnt und die Geschwindigkeitsvorteile sind beachtlich.

[Nersgatt]

So, nun geht es.

Ich habe folgendes gemacht:
1. Eine Funktion, die mir eine Liste der Tabellenfelder zurückliefert. Dabei kann die Funktion auch Feldnamen durch etwas anderes ersetzen:

Delphi-Quellcode:

function xxx.GetFieldList(strTable: String; trans : FBTransaction; ReplaceFields, Replace : Array Of String): string;
var c : FBCommand;
    dr : FBDataReader;
    i : Integer;
    bReplaced : Boolean;
    strField : String;
begin
  {Gibt eine Liste der Felder der Tabelle zurück und ersetzt dabei
   ggf. die angegebenen String.}

  if length(ReplaceFields) <> length(Replace) then
    raise(Exception.Create('Die Anzahl der Elemente in ReplaceFields und Replace muss gleich sein!'));

  result := '';
  c := FBCommand.Create('SELECT TRIM(RDB$FIELD_NAME) FROM RDB$RELATION_FIELDS WHERE UPPER(RDB$RELATION_NAME) = UPPER(@TABELLE) ORDER BY RDB$FIELD_POSITION', fbCon);
  try
    c.Transaction := trans;
    c.Prepare;
    c.Parameters.add('@TABELLE', fbdbtype.VarChar).Value := strTable;
    dr := c.ExecuteReader;
    while dr.Read do
    begin
      strField := dr.GetString(0);

      bReplaced := False;
      i := Low(ReplaceFields);
      while (not bReplaced) and (i <= high(ReplaceFields)) do
      begin
        if ReplaceFields[i] = strField then
        begin
          strField := Replace[i];
          bReplaced := True;
        end;

        inc(i);
      end;

      if result <> '' then
        result := result + ',';
      result := result + strField;

    end; {while dr.read}
    dr.Close;

  finally
    c.Free;
    dr.Free;
  end;

end;

Meine Routine zum kopieren sieht jetzt so aus (Auszug):

Delphi-Quellcode:

      
      strFields := GetFieldList('Buchungen', trans, [], []);
      strFields2 := GetFieldList('Buchungen', trans, ['ID', 'DATUM'], ['CAST(@IDZIEL AS INTEGER) AS ID', 'CAST(@DATUM AS DATE) AS DATUM']);

      c.CommandText := 'INSERT INTO BUCHUNGEN ' +
                       '(' + strFields + ') ' +
                       ' SELECT ' + strFields2 +
                       ' FROM BUCHUNGEN WHERE ID = @IDQUELL';
      c.Prepare;
      c.Parameters.Add('@IDZIEL', fbdbtype.Integer).Value := TObject(iID);
      c.Parameters.add('@IDQUELL', fbdbtype.Integer).Value := TObject(iBuchungID);
      c.Parameters.add('@DATUM', fbdbtype.Date).Value := TObject(dDatum);
      c.ExecuteNonQuery;

      trans.Commit;

Kritik ist willkommen. :mrgreen:

Gruß,
Jens

[Jürgen Thomas]

Hallo Jens,

Zitat:

Zitat von Nersgatt

Es gibt in .NET ein Dataset, das hat aber mit dem TDataSet nicht viel zu tun. Ist ein ganz anderes Konzept.

deshalb habe ich bisher mit einem Vorschlag gezögert. Da Du Versuche mit SELECT angegeben hast, habe ich vermutet, dass es Dir um eine Lösung innerhalb der Datenbank geht; dann ist der DbProvider (hier: FbClient) unwichtig.

Wenn Du aber auch eine Lösung innerhalb des DataSet (des NET-DataSet, nicht von Delphi-TDataset) in Betracht ziehst, kannst Du so vorgehen:

• Hole die gewünschten Daten per FbDataAdapter.Fill in das DataSet.
• Setze DataSet.EnforceConstraints auf false.
• Kopiere die gewünschte Zeile mit DataTable.ImportRow.
• Setze den ID-Wert, je nach Bedarf mit AutoIncrement innerhalb der DataTable oder durch Abruf des Generators (d.h. aus der internen Tabelle RDB$GENERATORS bzw. mit einem FbCommand über NEXT VALUE)
• Speichere die Daten mit DbDataAdapter.Update

Gruß Jürgen

PS. Deine Lösung, die Du inzwischen geschrieben hast, kann auch sinnvoll sein. Ich werde sie mir gleich genauer durchlesen.
So, nachdem der Forum-Server wieder bereit ist, hier mein Kommentar:

Grundsätzlich ein mögliches Verfahren, zumal Du es für Deine Bedürfnisse etwas erweitert und verallgemeinert hast. Nur ein paar Anmerkungen:

• In der konkreten Situation ist eine Transaction wahrscheinlich vernünftig. Wichtig ist aber, dass unter ADO.NET eine DbConnection nur so kurz wie möglich geöffnet sein soll und baldmöglichst wieder geschlossen wird.
• Bei strFields2 kannst Du auf CAST und AS ID verzichten. Wichtig ist, dass die Datentypen übereinstimmen; aber das tun sie ja bei Deiner Konstruktion.
• Du arbeitest mit NET 1.1, nicht wahr? Sonst wäre Parameters.AddWithValue vorzuziehen.
• Aber auch bei Dir geht es einfacher und trotzdem typsicher:
  
  Delphi-Quellcode:

        c.Parameters.Add('@IDZIEL', fbdbtype.Integer).Value := iID;

Jürgen

[nahpets]

Hallo,

das sollte Deiner Aufgabenstellung gerecht werden ;-)

[mkinzler]

Man könnte Testen ob man mit einem Execute-Block noch etwas rausholen kann

[Nersgatt]

Hallo Thomas,

vielen Dank für die ausführliche Antwort.

Zitat:

Zitat von Jürgen Thomas

Wenn Du aber auch eine Lösung innerhalb des DataSet (des NET-DataSet, nicht von Delphi-TDataset) in Betracht ziehst, kannst Du so vorgehen:

• Hole die gewünschten Daten per FbDataAdapter.Fill in das DataSet.
• Setze DataSet.EnforceConstraints auf false.
• Kopiere die gewünschte Zeile mit DataTable.ImportRow.
• Setze den ID-Wert, je nach Bedarf mit AutoIncrement innerhalb der DataTable oder durch Abruf des Generators (d.h. aus der internen Tabelle RDB$GENERATORS bzw. mit einem FbCommand über NEXT VALUE)
• Speichere die Daten mit DbDataAdapter.Update

Wenn der Vorschlag etwas früher gekommen wäre, hätte ich die Lösung in Betracht gezogen. Aber die jetzige Lösung finde ich noch etwas besser, weil sie näher an der Datenbank ist. Das eigentliche Statement wird auf dem Server ausgeführt.

Zitat:

So, nachdem der Forum-Server wieder bereit ist, hier mein Kommentar:

Grundsätzlich ein mögliches Verfahren, zumal Du es für Deine Bedürfnisse etwas erweitert und verallgemeinert hast. Nur ein paar Anmerkungen:

• In der konkreten Situation ist eine Transaction wahrscheinlich vernünftig. Wichtig ist aber, dass unter ADO.NET eine DbConnection nur so kurz wie möglich geöffnet sein soll und baldmöglichst wieder geschlossen wird.

• Warum? Ist es nicht unnötige Last, immer wieder die Verbindung zu öffnen und zu schließen?
  
  
  Zitat:

  Bei strFields2 kannst Du auf CAST und AS ID verzichten. Wichtig ist, dass die Datentypen übereinstimmen; aber das tun sie ja bei Deiner Konstruktion.

  ---

  Dass ich auf das CAST verzichten kann, war mir nicht wirklich bewusst, weil ich solche Dinge immer im IBExpert vorbereite. Dort muss man CAST verwenden, weil man ja für die Parameter keinen Datentypen angeben kann.
  
  
  Zitat:

  Aber auch bei Dir geht es einfacher und trotzdem typsicher:
  

  Delphi-Quellcode:

        c.Parameters.Add('@IDZIEL', fbdbtype.Integer).Value := iID;

  ---

Wird bei mir vom Compiler mit

Zitat:

[Pascal Fehler] UnitPaulCommon.pas(75): E2010 Inkompatible Typen: 'Object' und 'Integer'

quittiert.

Gruß,
Jens

[Jürgen Thomas]

Hallo Jens,

Zitat:

Zitat von Nersgatt

Hallo Thomas,

ich komme nicht aus Süddeutschland, wo oft zuerst der Nachname und dann der Vorname genannt wird. Da in Foren das Duzen üblich ist, bevorzuge ich die Anrede mit "Jürgen".

Zitat:

Aber die jetzige Lösung finde ich noch etwas besser, weil sie näher an der Datenbank ist. Das eigentliche Statement wird auf dem Server ausgeführt.

Das verstehe ich, und das finde ich auch gut.

Zitat:

Warum? Ist es nicht unnötige Last, immer wieder die Verbindung zu öffnen und zu schließen?

Nein. Suche einmal in der SDK-Doku/MSDN Erläuterungen zu Verbindungspooling (welcher DbProvider dabei betrachtet wird, ist gleichgültig; ich empfehle wegen der Bedeutung den MS-SQL Server).

Zitat:

Wird bei mir vom Compiler mit

Zitat:

[Pascal Fehler] UnitPaulCommon.pas(75): E2010 Inkompatible Typen: 'Object' und 'Integer'

quittiert.

Oops. Unter C# bin ich gewöhnt, dass alles Objekte sind; also ist auch ein Integer ein Object und kann (in dieser Richtung) direkt zugewiesen werden. Unter Pascal scheint das nicht zu gelten.

Weiterhin viel Erfolg! Jürgen

[shmia]

Hier ist eine sehr elegante Lösung für dein Problem:
Datensatz duplizieren