Parameter unter Firedac

[Sir Rufo]

Siehe englische Hilfeseite zu TFDParam.AsStream

Zitat:

The assigned TStream object will be owned by this TFDParam .

Das herunterskalieren auf ein JPEG ist ja ok, aber diese wilde hin- und herkopiere ist zum großen Teil überflüssig.

Zumal ein FDQueryMain.Params[0].Assign( MyImage ); das auch erledigt. Also ist der Stream schonmal komplett überflüssig.

Eine GUID ist auch nur eine Bytefolge und kann mit System.Sysutils.TGUIDHelper ganz gemütlich in ein ByteArray geschoben werden.

[Delbor]

Hi SirRufo

Zitat:

Eine GUID ist auch nur eine Bytefolge und kann mit System.Sysutils.TGUIDHelper ganz gemütlich in ein ByteArray geschoben werden.

Danke für die Info!! Auf jeden Fall auf den von mir besuchten Seiten habe ich nichts über TGUIDHelper entdecken können. Wobei natürlich wie immer gilt: wegen der Fülle von Infos kann auch mal was überlesen werden.

Zitat:

Zumal ein FDQueryMain.Params[0].Assign( MyImage ); das auch erledigt. Also ist der Stream schonmal komplett überflüssig.

Eventuell dämliche Nachfrage: Was erledigt das auch? Das Einfügen des Bildes in einer für die DB akzeptablen Grösse?
Wenn ich eine Bitmap erstelle und diese bearbeite, will ich sie so, wie ich sie bearbeitet habe, in der DB. Ansonsten müsste ich ein Bild jedesmal neu als Bitmap erstellen und neu bearbeiten, wenn Bedarf besteht.

Gruss
Delbor

[Sir Rufo]

Statt Grafik in Stream und Stream an Parameter einfach nur Grafik per Assign an den Parameter.

[Delbor]

Hi Sir Rufo
Erstmal danke für den Tip:

Zitat:

Statt Grafik in Stream und Stream an Parameter einfach nur Grafik per Assign an den Parameter.

Und nun lass mich raten: da Grafiken binäre Daten sind, hätte das auch unter DBExpress funktioniert?

Gruss
Delbor

[Sir Rufo]

Das funktioniert mit allen Klassen, die von TPersistent abgeleitet sind und IStreamPersist implementieren.

Und TGraphic erfüllt dieses Kriterium - siehe: TGraphic

Korrektur: TStrings wird beim Assign gesondert behandelt und nicht über IStreamPersist

[Delbor]

Hi zusammen

In Bezug auf den GUID tut sich noch ein Problemm auf. Um mich selbst zu zitieren:

Zitat:

Allerdings ist mir ein Designfehler unterlaufen. Ich habe das Feld für den GUID der Bildtabelle verpasst, aber eigentlich gehört das Ding in die Kategorientabelle - die enthält "Kategorien" (diesen Namen habe ich seinerzeit falsch gewählt), die jedoch eigentlich den Ordnernamen auf der Festplatte entsprechen. Diese Ordner enthalten meist Fotos, die bei einem bestimmten Ereignis entstanden sind, können aber auch solche enthalten, die sich auf mehrere Ereignisse beziehen.

• Grundsätzlich kann ich über ein Eingabefeld eine neue Kategorie erzeugen. Die muss dann ichts mit einem Ordnernamen gemein haben.
• Die Kategorien können in der DB jederzeit geändert werden. Das wird vor allem der Fall sein, wenn sich die Rohdaten im Quellordner auf mehrere Ereignisse beziehen.
• Auf diese Weise haben dann Bilder in der DB plötzlich keinen zugehörigen Rohdaten-Ordner mehr auf der Festplatte

Das bedeutet aber, dass ich so vorgehen muss, wie ich es bisher umgesetzt habe - die eigentliche Bildtabelle enthält neben den 3 Blobfeldern auch ein Feld für den GUID.
Und das wiederum widerspricht eigentlich den Normalisierungsregeln: Ich hab jetzt nur mal testweise Bilder aus einem Ordner in die DB aufgenommen - 444 Stück, und jedem wird der selbe GUID zugeordnet.

Wie liesse sich das lösen?

Gruss
Delbor

[Sir Rufo]

Was entspricht nicht der Normalisierung? Die GUID an dem Bild zu speichern?

Wie kommst du da drauf? Den eindeutigen Pfad zu der Bilddatei bekommst du doch nur über die GUID des Ordners und dem relativen Pfad zu der Datei. Als gehören diese Informationen auch zu dem Datensatz.