DBExpress Firebird V2.5 Unicode Blob-Fields

[lowmax_5]

Hallo,

setzt jemand erfolgreich die Kombination DBExpress Firebird V2.5 Unicode Blob-Fields
unter XE2 ein?. Einen sauberen und fehlerfreien Zugriff auf die DB bekomme ich speziell mit Blob-Fields nicht hin.
Hat jmd. andere Erfahrungen gemacht oder ist die FB-Untersützung in XE2 einfach nur Murks?

[Bernhard Geyer]

Was sind Unicode Blob Field.

Blob heißt ja "Binary Large Object". Wie soll da irgendein Unicode-Einstellung wirken?

[lowmax_5]

In FB kann der BlobTyp 'Text' gewählt werden, den dann wiederrum ein Characterset zugewiesen kann.

[Perlsau]

Zitat:

Zitat von lowmax_5 (Beitrag 1176299)

Hallo, setzt jemand erfolgreich die Kombination DBExpress Firebird V2.5 Unicode Blob-Fields
unter XE2 ein?.

Ja.

Zitat:

Zitat von lowmax_5 (Beitrag 1176299)

Einen sauberen und fehlerfreien Zugriff auf die DB bekomme ich speziell mit Blob-Fields nicht hin.

Du schreibst, "kein fehlerfreier Zugriff", verschweigst uns aber, welcher Fehler auftritt. Du möchtest doch, daß man dir weiterhilft, oder nicht? Wenn du zum Arzt gehst, dann erzählst du doch auch, was dir wehtut. Genau das ist die Fehlermeldung, die hier fehlt.

Zitat:

Zitat von lowmax_5 (Beitrag 1176299)

Hat jmd. andere Erfahrungen gemacht oder ist die FB-Untersützung in XE2 einfach nur Murks?

Ja. Nein.

Niemand hier weiß, was du machst und was was du schon versucht hast. Oder glaubst du an Hellseherei?

Wenn du Neuling in Sachen DB-Entwicklung bist, schau dir diese kurze Anleitung an (Post #7).

[lowmax_5]

Hallo,

die Frage war schon so gemeint, ob diese Kombination generell funktioniert, da ich die Infomation gefunden hatte, dass seit D2010 der Firebird-Treiber einen Bug mit Blob-Feldern hat.

Aber ich kann die Frage gerne auch konkreter stellen: Ein Problem gibt es speziell mit TextBlobs, wenn diese
mit Unicode UTF8 angesteuert werden. Verwende ich nur Varchars kann ich mit DBEdit die Daten korrekt sehen und editieren. Verwende ich jedoch ein TextBlob mit einer DBMemo-Komponente gibt es beim Start gleich eine Fehlermeldung
und die Unicodezeichen (Kyrillisch) werden nicht korrekt dargestellt.

Im DBX-Treiber verwende ich die Parameter

Code:

ServerCharSet=UTF8
UseUnicode=True
EnableMemos=True

Fehlermeldung:

Code:

TDBXError mit der Meldung 'invalid BLOB ID'

Testtabelle:

Delphi-Quellcode:

SET SQL DIALECT 3;

CREATE TABLE KUNDEN (
    ID     INTEGER NOT NULL,
    NAME1   VARCHAR(100) CHARACTER SET UNICODE_FSS,
    MEMO1  BLOB SUB_TYPE 1 SEGMENT SIZE 80 CHARACTER SET UNICODE_FSS,
);
ALTER TABLE KUNDEN ADD CONSTRAINT PK_KUNDEN PRIMARY KEY (ID);

[Morphie]

UNICODE_FSS ist veraltet... was passiert, wenn du UTF8 nimmst?

[lowmax_5]

Zitat:

UNICODE_FSS ist veraltet... was passiert, wenn du UTF8 nimmst?

Die Fehlermeldung ist weg und Daten lassen sich posten. Die Blobfelder werden aber weiterhin nicht korrekt dargestellt.
(Nur Kästchen)

[Perlsau]

Zitat:

Zitat von lowmax_5 (Beitrag 1176446)

Zitat:

UNICODE_FSS ist veraltet... was passiert, wenn du UTF8 nimmst?

Die Fehlermeldung ist weg und Daten lassen sich posten. Die Blobfelder werden aber weiterhin nicht korrekt dargestellt.
(Nur Kästchen)

Kann ich bestätigen (UTF8-Text-Blobfeld und mehrere VarChars). Teilweise werden die Posts gar nicht übernommen (Blob), teilweise wird im DB-Memo Schrott dargestellt.

[Morphie]

Hier gibt es wohl exakt das gleiche Problem:
https://forums.embarcadero.com/threa...ssageID=445267

Mein Tipp: vergiss DBExpress und investiere besser in ordentliche Komponenten. (z.B. IBDAC)

[Perlsau]

Zitat:

Zitat von Morphie (Beitrag 1176451)

Hier gibt es wohl exakt das gleiche Problem:
https://forums.embarcadero.com/threa...ssageID=445267

Mein Tipp: vergiss DBExpress und investiere besser in ordentliche Komponenten. (z.B. IBDAC)

Ich krieg hier noch zusätzlich diese Meldung, wenn ich im DB-Navigator den Button "Aktualisierung durchführen" klicke:
Im Projekt ProjectTest1.exe ist eine Exception der Klasse EDatabaseError mit der Meldung 'Datensatz nicht gefunden oder von einem anderen Benutzer geändert' aufgetreten.

[lowmax_5]

Zitat:

Zitat:

Hier gibt es wohl exakt das gleiche Problem:
https://forums.embarcadero.com/threa...ssageID=445267

Mein Tipp: vergiss DBExpress und investiere besser in ordentliche Komponenten. (z.B. IBDAC)

Daran habe ich auch schon als Lösung gedacht. Ich konnte es nur nicht glauben, dass Embarcadero so einen kritischen Fehler über eine so lange Zeit nicht behebt und habe den Fehler bei mir selbst gesucht. Das wäre dann also der Abschied vom DBExpress-Framework... :oops:

Ich hoffe dass dieses auch von den Embarcadero-Leuten gelesen wird....

[Perlsau]

[QUOTE=lowmax_5;1176454][QUOTE]

Zitat:

Ich hoffe dass dieses auch von den Embarcadero-Leuten gelesen wird....

Könnte auch Absicht sein, weil Emba es ja viel lieber sieht, wenn man ihre Interbase-DB verwendet statt Firebird ...

[mkinzler]

Wobei, sei ja nachträglich einen dbExpress-Treiber für FireBird entwickelt haben

[lowmax_5]

Die ganze Firebird-Unterstützung für DBExpress ist ein Witz, wenn diese elementare Funktion nicht zur Verfügung steht.
Für mich war dieses ein wichtiger Kaufgrund für XE2.

Fehler können passieren, doch diese müssen, wenn sie kritisch sind, und/oder eine gesamte Nutzung unmöglich machen umgehend gefixt (Workround) werden.

[Bernhard Geyer]

Also im Bereich DBExpress oder allgemein ist man mit den Lieferungen die der IDE beiliegen schlecht beraten. Sinnvoller ist es Komponten wie von DevArt zu kaufen und stattdesen statt der Enterprise nur die Pro-Version der IDE zu nehmen.
Diese 3th-Party-Hersteller liefern eigentlich fast immer innerhalb einer 1 Woche Lösungen zu Fehler (oft als Liste geänderte Quellcodezeilen die man auch in ältere Releases einbauen kann). Dieses Release-Zeiten kann sich aber Aufwandstechnisch der IDE-Hersteller nicht leisten.

[lowmax_5]

Ich habe gerade gesehen, dass es bei DevArt auch einen Firebird-Treiber für DBExpress gibt. http://www.devart.com/dbx/interbase/.
Der Treiber zum Kauf sollte die bestehenden Probleme dann wohl lösen...

[Bernhard Geyer]

Zitat:

Zitat von lowmax_5 (Beitrag 1176467)

Der Treiber zum Kauf sollte die bestehenden Probleme dann wohl lösen...

Hab zwar "nur" MySQL im Einsatz, aber bisher konnte DevArt alle probleme immer sehr zügig lösen. Damals als das Problem mit der geänderten Passwortverschlüsselung bei MySQL aufgetreten ist war es das beste das ich von einer anderen 3th-Party-Implementierung nach DevArt gewechselt bin :thumb:

[Rainer Wolff]

Hat jemand für diesen Thread inzwischen eigentlich eine andere Lösung ausser bei Drittherstellern einkaufen zu gehen?

Gruß Rainer

[lowmax_5]

Hallo,

ich habe das Projekt von DBExpress nach IBDAC umgestellt und es läuft auch mit Unicode sehr gut. Die Investition in die Komponenten hat sich gelohnt, zumal ich deutlich schneller bei der Entwicklung bin, da nicht so viele 'Klimmzüge' notwenig sind. Insbesondere das manuelle Transactionhandling ist sehr gut gelöst.

lowmax

[Rainer Wolff]

Grummel...

Die dbx-Komponenten haben ja eigentlich den Vorteil, dass ich auf Datenbanken verschiedener Hersteller zugreifen kann, was ich ja auch in Teilen nutze/brauche.
Von daher möchte ich eigentlich nicht auf andere Komponenten wechseln, zumal meine ganzen Projekte teils auf eine gemeinsame Bibliothek zugreifen und ein Umstieg weite Kreise über die gemeinsame Bibliothek und alle Einzelprojekte ziehen würde.

Aber nachdem ich jetzt gerade über einen weiteren Fehler in dem ganzen Zusammenhang gestolpert bin, der mich einen Tag Fehlersuche gekostet hat, bin ich echt sauer.

Das Filtern in meinem Clientdataset mit foCaseInSensitive und einem like % Ausdruck funktioniert nämlich auch nicht mehr, sobald die Datenbank UTF8 ist.

[lowmax_5]

Hat jmd. vielleicht XE3 und kann prüfen, ob diese Probleme dort auch bestehen?

Unter XE2 sind die Blob/UTF8 Probleme definiv da und in den Upates wurde diess Problem nicht gelöst.

lowmax

[D-User]

das Problem gabs schon bei D2010.
Liess sich umgehen, wenn man mittels Varianten mit Memos (merke: NICHT DBMemos)
agiert. Nicht toll, man muss dann halt selber auf Ereignisse reagieren etc. Sobald es Master-Details wird, wirds dann noch etwas haariger. Geht allerdings, aber ganz sicher nicht im Sinne des Erfinders. Nix was man noch irgendwo posten könnte.

DA es aber ging, geh ich davon aus dass die Nicht-Korrektur wie oben schon bemerkt tatsächlcih strategische Absicht war (FB-Benachteiligung gg.IB), das Problem ist schon mal vor ner Weile gepostet worden wenn ich mich recht erinnere.