Insert und TBlobField

[Captnemo]

Ok, wahrscheinlich zum 100.sten Mal :wink:

Wenn ich eine Tabelle mit einem Blob-Feld über SQL per INSERT um eine Zeile erweitern will, dann hab ich ja immer das Problem, dass ich das BLOB nicht direkt mit übergeben kann.

Nun haben meine Tabellen eigentlich immer ein Feld LFDNR, eine laufende Nummer mittels AutoInc. Das wäre für mich eigentlich der einzige, eindeutige Indikator für eine Zeile. Diesen Wert kenne ich aber nach der INSERT-Anweisung nicht, weil er ja erst bei EXEC erzeugt wird.

Nun gehe ich immer den "umständlichen" Weg, erstmal irgendein Feld zu mißbrauchen, und dort einen Wert per Insert reinzusetzen, den ich auf jeden Fall eindeutig habe (was ich ja irgendwie nicht wirklich garantieren kann).
Danach hole ich mir per Select die Zeile wieder in mein Query und setzte dann erst mittels MemoryStream das Blobfeld.

Soweit so gut. Aber letztlich kommt mir das sehr umständlich und auch irgendwie unsauber vor.

Mal ausgehend davon, dass diese Datenbank von vielen Usern genutzt wird, und diese auch alle ständig viele Veränderungen vornehmen. So kann es doch passieren, das sich zwischen dem Insert und dem kopieren per Stream schon wieder etwas verändert. Besser wäre es ja, das Blob gleich beim Insert mit den richtigen Daten zu füllen. Oder?

Ist das wirklich die einzige Möglichkeit? Aber eine andere hab ich bis jetzt auch nicht gefunden.
Was sagt ihr dazu?

[shmia]

Zitat:

Zitat von Captnemo

Wenn ich eine Tabelle mit einem Blob-Feld über SQL per INSERT um eine Zeile erweitern will, dann hab ich ja immer das Problem, dass ich das BLOB nicht direkt mit übergeben kann.

Wirklich ?
Du kannst sehr bequem Daten in eine Tabelle einfügen, indem du eine SQL-Query nimmst:

Delphi-Quellcode:

ADOQuery1.SQL.Text := 'SELECT * FROM tabelle WHERE 0=1'; // beachte die Where-Bed.
ADOQuery1.Open;

ADOQuery1.Edit;
ADOQuery1['Datum'] := Now;
ADOQuery1.FieldByName('Blobfeld').LoadFromFile(....);
ADOQuery1.Post;

Gegenüber einer INSERT-Anweisung hast du damit zwar einen gewissen Leistungsverlust, aber damit kann man leben.

Ich verwende übrigens niemals Auto-Inc Felder; die haben einfach zu viele Nachteile.

[Captnemo]

Dank dir erstmal für den Beitrag. Aber ich muß doch nochmal nachfragen ;-)

'where 0=1' ??
Soll ich mir das jetzt so vorstellen, dass ich eine leere Datenmenge selectierst? Und per Edit dann eine hinzufüge? Dachte immer dafür wäre ein Append gedacht. Was allerdings bei einem Query fehlschlägt glaube ich.
Vielleicht kannst du mir das noch mal erklären.

2. Frage: Was für ein Nachteil hat denn ein Autoinc-Feld? Ich hab bisher noch keines gefunden, es sei denn ich hab immer geschickt drumrum programiert *ggg*

[Captnemo]

Ok, das mit dem "where 0=1" hab ich jetzt verstanden. Ich hab noch mal danach gegooglet und bin dann auf deinen Beitrag http://www.delphipraxis.net/internal...ct.php?t=26406 gestoßen. Dort ist das ja noch mal erklärt.

Aber warum jetzt Autoinc-Felder nachteile haben, frage ich mich immer noch ;)

[marabu]

Hi.

Da bei einer updateable query alle internen Kontrollblöcke aufgebaut werden, unabhängig von der Anzahl der belegten record buffer, möchtest du verhindern, dass auch nur ein einziger unbenötigter Datensatz über das Netz geschickt wird. Die einfachste Methode ist ein WHERE clause, der FALSE als Ergebnis liefert.

Bei AUTOINC Feldern ist allgemein festzustellen, dass diese Felder nicht der Kontrolle deiner Anwendung unterliegen. Sie verwenden oft einen unzugänglichen Generator - ist der korrupt, dann gibt es keine oder nur sehr umständliche Wege zur Wiederherstellung der Konsistenz.

Besser sind da offene Generatoren. Sie bieten dir eine gekapselte Schnittstelle für die Manipulation und das Schlüsselfeld bleibt unter deiner Kontrolle, auch und erstrecht bei Reparaturen an der Datenbank.

Grüße vom marabu