Zeos und bestimmte Strings (Bug) [Gelöst]

[MmVisual]

Hallo,

Mit der Zeos Komponente habe ich hin und wieder das Problem dass Strings zerhauen werden wenn da eine bestimte konstellation im String drin steht. Ich bin mir nicht sicher woran das liegt, bzw. wo ich im Zeos Quellcode suchen muss um dem Problem auf die schliche zu kommen.
Es betrifft unterschiedliche Datenbanken, daher denke ich es muss irgend etwas mit der String Konvertierung sein.
Es kann auch sein dass ich entwas an der Konfiguration der TZConnection anders parametrieren muss, damit es richtig geht.

Ein Beispiel Projekt habe ich erstellt, in dem wird SQLite als Memoy DB genutzt, die Tabelle erstellt und man kann einen Datensatz erzeugen, wenige Zeilen Code die das Problem zeigen.

In die DB soll der Text gespeichert werden: '{ "Induktvität [H]" : "0,0068", "R [Ω]"'
Nach dem Post hat Zeos das draus gemacht: '{ "Induktvität [H]" : "0,0068", "R [Ω]"'

ZeosUTF8.png (11.07 KiB) 5353 mal betrachtet

Die Umlaute und Sonderzeichen werden schon falsch in die DB rein geschrieben, andere Tools zeigen das dann ebenfalls falsch an.

Zeos intern:
Zeos konvertiert in der Regel selbstständig die Codierung der Datenbank zur Codierung innerhalb der EXE, ich vermute da ist irgend etwas nicht ganz richtig. Sehr oft kommt es im Zusammenhang mit dem ° Zeichen vor, z.B. wen man °C verwendet. Es hängt auch damit zusammen wie viele Textzeichen insgesammt man verwendet, es kann sein dass man noch ein Leerzeichen dazu tippt, dass dann der Text korrekt bespeichert wird. UTF8 Zeichen können 1-4 Byte lang sein, wenn man so ein Zeichen kopieren möchte muss man das beachten, eventuell ist da auch das Problem, denn es tritt nur dann auf wenn man andere Zeichen als ASCII zusätzlich im String hat.

Vielen Dank für die Hilfe, bzw. Tipps wo ich suchen soll, VG Markus.

TestZeosUTF8.zip

(1.35 MiB) 92-mal heruntergeladen

Edit:
Hier kann die Lösung/Fix geladen werden: viewtopic.php?p=138416#p138416

[MmVisual]

Beim Durchdebuggen bin ich in den "ZDbcResultSet" angekommen,
Hier habe ich mal die Codepage für die Konvertierung mal abgeändert, danach wurden die Zeichen richtig eingetragen.

ZDbcResultSet_4910Mod.png (58.34 KiB) 5338 mal betrachtet

Nur natürlich ist diese Änderung an der Stelle nicht richtig. Es ist noch nicht der Bugfix.
Eigentlich müsste "FCurrentCodePage" für Lazarus auf "zCP_UTF8" gesetzt werden.

[MmVisual]

Die Änderung von vorhin habe ich rückgängig gemacht und nun in ZStreamBlob geändert:

An der stelle steht auch ein Kommentar dass es Zeos nicht möglich ist die korrekte Codepage heraus zu finden, daher habe ich bei "FPC" das fix auf UTF8 gesetzt.
Ich teste das noch...

ZStreamBlob_168Mod.png (132.78 KiB) 5334 mal betrachtet

[MmVisual]

Mir stellt sich hier die Frage ob eigentlich nicht "ZEncoding.pas" bereits falsch ist.

Ja, das gibt die richtige Codepage für das Betriebssystem Windows zurück, jedoch ist das doch für Lazarus irrelevant, da Lazarus alles intern in UTF8 handhabt,
Da müsste eigentlich die Codepage in der Funktion "procedure SetZOSCodePage;" beim FPC auf UTF8 gesetzt werden.

Was meint ihr dazu?

[charlytango]

Obwohl ich hier direkt in der Sache keinen Hinweis geben kann, ist es mir als alten Datenbanker ein dringendes Bedürfnis meinen Senf dazu zu geben.

Sehe ich das richtig dass hier ein Bemerkungsfeld für ein Datenkonstrukt genutzt bzw missbraucht wird?
In meiner Welt wäre das ein absolutes No-Go.
Und emotional formuliert: Mögen die Transportformate wie XML, JSON und Co aus den Datenbanken verbannt sein/bleiben.

Kleine Historie:
Natürlich habe ich derartige Dateiformate schon vor der Einführung von HTML et al benutzt, aber niemals in DBs und sie haben mir durch die Unart sie in Datenbanktabellen zu stopfen im Laufe der Zeit erheblichen Ungemach bereitet.
Mit dem Aufkommen sogenannter "Webentwickler" mit mangelnden Grundkenntnissen im DB-Design hat sich das noch mehr verbreitet. Letztens habe ich so etwas in einem Kassensystem gefunden, was es unmöglich gemacht hat direkte Auswertungen von außen zu erstellen.

Natürlich weiß ich dass mittlerweile DBMS wie Oracle, MSSQL und vermutlich auch andere solche Konstrukte in irgend einer Form unterstützen, mir erschließt sich der Sinn jedenfalls trotzdem nicht, wenn ich eine "Tabelle" in eine Tabelle schreiben soll.

Aber möglicherweise sind das nur die Ansichten eines Clowns... oder leidgeprüften DB-Entwicklers.

[MmVisual]

Das siehst du falsch, es passiert auch bei "Normalem" Text in den TDBMemos, es passiert meist dann wenn man ein °C drin hat und noch andere Umlaute.

Abgesehen davon ist das JSON Format perfekt um z.B. von ganz vielen Artikeln die vielen unterschiedlichen Technischen Daten rein zu bekommen, damit kann jeder Anwender selbst definieren welche technische Daten er denn so alles hat und kann darin sogar suchen mit z.B. Wert > n und Wert < n. Und zu guter letzt kann man ein JSON Feld direkt als Spalte in der Tabelle zeigen als wäre es eine echte Datenbankspalte.

[MmVisual]

Ich habe nun die Änderung in "ZStreamBlob" wieder rückgängig gemacht und dafür in ZEncoding dies bei FPC fix auf UTF8 gesetzt. Damit sollte es für sämtliche Strings in allen Bereichen von Zeos nun richtig gehen und nicht nur bei Blobs.
Meine ersten Tests sehen gut aus.

ZEncoding_2600.png (64.23 KiB) 5323 mal betrachtet

Hier die Datei für Zeos V7.2.14:

ZEncoding.zip

(25.87 KiB) 99-mal heruntergeladen

[Soner]

Bei mir erscheint alles richtig:

Screenshot1.jpg (15.22 KiB) 5300 mal betrachtet

Ich habe die ZEOS-Version 7.2.4-stable. Ich kann mich errinern, dass die neue Version auch bei mir für Sonderzeichen und Umlaute merkwürdige Zeichen angezeigt hat. Es gab sogar noch merkwürdiges Verhalten, wenn man TFBAdmin oder TFBEventMonitor im Programm hatte, ich kann mich nicht erinnern welche, funktionierte das Programm nicht.
Da ich keine Zeit dafür hatte, bin ich bei mein Version geblieben.
Teste mal dein Programm mit 7.2.4-stable.

[MmVisual]

Weis jemand was mit Egonhugeist, einem Zeos Entwickler passiert ist? Noch vor einem Jahr war er sehr aktiv, dann auf einmal keine Updates mehr von ihm.

Die 7.2.4 kann ich nicht nehmen, ich meine da waren noch Bugs in MsSQL drin (ist jetzt auch schon lange her).

[af0815]

Die 7.2.4 kann ich nicht nehmen, ich meine da waren noch Bugs in MsSQL drin (ist jetzt auch schon lange her).

Zeoslib hat ein eignes Forum https://zeoslib.sourceforge.io/

An und für sich gibt es den 8.0 Branch schon eine ganze Weile, nur halt nicht in OPM.

Wo bei aktuell einige Personen verschwinden. Egonhugeist seit ca. Februar nicht im Zeolib-Forum mehr gesehen, GetMem von OPM seit kurzen aus dem englischen Forum verschwunden. Irgendwie aktuell fast bedrohlich.

Bei Zeos macht jetzt marsupilami die Hauptarbeit soweit ich das überblicke, zumindest nach außen hin.

[charlytango]

Das siehst du falsch, es passiert auch bei "Normalem" Text in den TDBMemos, es passiert meist dann wenn man ein °C drin hat und noch andere Umlaute.

Mir ging es hier nicht um das technische Problem der Sonderzeichen und Codepages.

Abgesehen davon ist das JSON Format perfekt um z.B. von ganz vielen Artikeln die vielen unterschiedlichen Technischen Daten rein zu bekommen, damit kann jeder Anwender selbst definieren welche technische Daten er denn so alles hat und kann darin sogar suchen mit z.B. Wert > n und Wert < n. Und zu guter letzt kann man ein JSON Feld direkt als Spalte in der Tabelle zeigen als wäre es eine echte Datenbankspalte.

Auch wenn ich bei einzelnen, ganz spezifischen Anforderungen einen kleinen Nutzen sehe (reines Ablegen unterschiedlicher Datenformate), überwiegt bei mir immer noch die Überzeugung dass diese Strategie in eine Sackgasse führt.
Ein JSON Format kann IMHO nichts was eine Tabelle nicht auch könnte.
Aber das wird sich erst zeigen wenn Daten aus diesen Feldern in Reports oder Berechnungen auftrauchen sollen.

Let's agree to disagree...

[MmVisual]

Ich nutze die Daten aus den JSON Feldern bereits erfolgreich in Berechnungen, diese Tabelle wird per SQL Befehl zusammen gebaut.
- Man wählt das Feld aus den JSON Daten aus
- Man kann ein Min und Max Wert eingeben
- In der Tabelle wird der eine Wert als extra Spalte angezeigt.
- geht auch mit mehreren Werten
- Die Datensätze, die in den JSON Daten das gewünschte Feld nicht enthalten haben werden automatisch nicht vom SQL Server zurück gegeben.
- Es schafft eine ungemeine Flexibilität um spezielle Kundenwünsche ab zu decken ohne dass man jedesmal die EXE ändern muss.

Hier mal ein Screenshot von der Anwendung der technischen Daten in meinem EleLa* Projekt

Bild1.png (42.7 KiB) 5245 mal betrachtet

Und hier der SQL Befehl dieser Abfrage:

Code: Alles auswählen

SELECT 
(REPLACE(JSON_UNQUOTE(JSON_EXTRACT(v.TecData, '$.\"R [Ω]\"')),',','.') + 0.0) AS TD_R, 
(REPLACE(JSON_UNQUOTE(JSON_EXTRACT(v.TecData, '$.\"Toleranz [%]\"')),',','.') + 0.0) AS TD_Toleranz, 
b.ID, v.ID AS VID, b.tree_typ_ID, b.Bezeichnung AS Bezeichnung,
b.Beschreibung AS BBeschr, b.Info as BInfo,
v.Bezeichnung AS VBez, v.Bemerkung AS VBemerk, v.Info as VInfo,
g.Bezeichnung AS CBez, v.SMD, v.SMD_Text, v.Pinout,
k.Bezeichnung AS KBez, l.LagerNr, l.Menge, v.Einheit, l.Haltbar, v.ArtikelNr, v.ArtikelNr2,
v.Barcode, l.Barcode AS LBarcode, v.EAN,
NULL AS AdrBez, NULL AS BestellNr,
NULL AS EPreis, NULL AS GPreis, NULL AS EPMenge, NULL AS VPEMenge
, b.AendDatum AS BAendDatum, v.AendDatum AS VAendDatum
FROM bauteilvariante v
LEFT JOIN bauteil b ON (b.ID = v.Bauteil_ID)
LEFT JOIN bauteilkiste l ON (v.ID = l.BauteilVariante_ID)
LEFT JOIN gehause g ON (g.ID = v.Gehause_ID)
LEFT JOIN kiste k ON (k.ID = l.Kiste_ID)
WHERE (b.Bezeichnung LIKE '%'
OR b.Beschreibung LIKE '%'
OR b.Info LIKE '%'
OR v.Bezeichnung LIKE '%'
OR v.Bemerkung LIKE '%'
OR v.Info LIKE '%'
OR v.SMD_Text LIKE '%'
OR l.LagerNr LIKE '%'
OR v.ArtikelNr LIKE '%'
OR v.ArtikelNr2 LIKE '%'
OR v.Barcode LIKE '%'
OR v.EAN LIKE '%'
OR l.Barcode LIKE '%'
)
 AND ((REPLACE(JSON_UNQUOTE(JSON_EXTRACT(v.TecData, '$.\"R [Ω]\"')),',','.') + 0.0) >= '50' )
 AND ((REPLACE(JSON_UNQUOTE(JSON_EXTRACT(v.TecData, '$.\"R [Ω]\"')),',','.') + 0.0) <= '10000' )
 AND ((REPLACE(JSON_UNQUOTE(JSON_EXTRACT(v.TecData, '$.\"Toleranz [%]\"')),',','.') + 0.0) <= '1' )
ORDER BY UPPER(v.Bezeichnung)

(* kann kostenlos von www.elela.de geladen werden)

[charlytango]

Hab nie bezweifelt dass es möglich ist und ich mag deine Leistung keinesfalls irgendwie schmälern. Respekt dafür. Die Einbindung in MariaDB zeigt nur dass dieser "Virus" schon weiter verbreitet ist als ich dachte.

Ich mag dieses Einzeilen-Hieroglyphen-Rumgefrickle weder in Regex noch anderswo, auch wenn es noch so gut funktionieren mag. Kann sein dass das an meiner eigenen EDV-Geschichte liegt oder an schlechte Erfahrungen gebunden ist. Egal.

fachlich: Hier wird eine Tabelle (=JSON) in einer Tabelle geführt. In meinem Kopf ist das eine Tabelle in Relation zur Artikeltabelle in vertikalisierter Form. Die ist in alle Richtungen dynamisch und man kann sie easy indizieren. Klar kann man auch Klimmzüge mit Virtual Computed Columns veranstalten, aber man muss nicht. Ich für meinen Teil sehe da keine Notwendigkeit für derartige JSON-Konstruktionen. Man erspart sich nur eine eigene Tabelle (vielleicht auch zwei wenn man den Normalisierungsgrad weiter treiben will) und erkauft sich das mit Komplexität. Aber ich kenne natürlich die Spec nicht.

Möchte nur dem nicht so versierten Leser zeigen dass so eine Strategie nicht alternativlos ist. Und jeder soll auf seine Art glücklich werden

Just my 3 cents and nothing else.

[MmVisual]

Prinzipiell finde ich "echte" Spalten natürlich auch besser. Alles was immer da ist und auch Dinge die als Querverbindungen zu anderen Tabellen genutzt werden würde ich niemals als JSON ausführen. Ebenfalls Dinge, die man ohnehin immer braucht.

Nutze ich bisher auch nur in diesem einen Fall, wo Anwender beliebige eigene Daten in die Datenbank bekommen können, und genau dafür ist es Perfekt. Es gibt auch keine Prüfung aus NULL oder Defaultwerte oder sonstige SIcherheit seitens der Automatismen der Datenbank, dafür ist JSON auch nicht da.

[af0815]

Die Einbindung in MariaDB zeigt nur dass dieser "Virus" schon weiter verbreitet ist als ich dachte.

Es ist kein neuer "Virus". Für xml gibt es das seit dem MS-SQL2000 als neues Feature, JSON geht seit dem MS-SQL2016. Und wenn man es sinnvoll verwendet ist es sogar eine gute zusätzliche Option - ich habe da mit xml gute Erfahrung gemacht. Aber zu denken das kann wie eine stinknormale Spalte verwendet werden, das sollte man tunlichst unterlassen - da hat charlytango sehr wohl recht. JSON und xml kann man als Sahnehäubchen betrachten - also "OnTop" bei einer guten Basis - sonst kommt man rasch in Teufels Küche.

Kurz gesagt, wenn du die JSON/XML Daten genaugenommen nicht brauchst, sondern nur zusätzlich vorhanden sind, dann passt es. Für Reports als zusätzliche Daten gut geeignet, damit man da nicht endlos viele unnötige Spalten braucht, oder die Anzahl sehr variable ist. Aber mit den Zeichensätzen kann das schon mal ziemlich problematisch werden, weil die können bei xml mal komplett anders sein, als die auf der Verbindung oder in der Datenbank.