[Gelöst] SQLite3 und fpreport - Zeichenkodierung

[MacWomble]

Hallo,

ich hoffe mir kann jemand einen Tipp geben. Ich habe zwei SQLite-Datenbanken, nach dem gleichen Gusto aufgebaut. Wenn ich nun mit dem fp-Reportdesigner einen Bericht erstelle, funktioniert dies bei der einen DB einwandfrei, bei der zweiten bekomme ich für Text und Memo-Felder nur kryptische Ausgaben. Dies habe ich auf zwei Rechnern getestet. Ich vermute, dass hierfür irgendeine Einstellung in der SQLite-DB verantwortlich ist. Sind aber beide auf UTF-8 eingestellt, wie auch die Reports.
Leider kann ich die Datenbanken nicht hochladen, da die Daten nicht öffentlich sind.

Das ganze unter linux Mint 20.2 und DB Browser for SQLite erstellt.

[Linkat]

Hallo MacWomble,
ich habe zwar noch nie mit dem fpreport gearbeitet, aber versuche mal den Font von deinem Memo zu ändern. Dein Problem erinnert mich an ein ähnliches Problem, das ich hatte.

Code: Alles auswählen

Memo1.Font.Name:=...

Viel Erfolg.

Gruß, Linkat

[MacWomble]

Danke, aber das hat auch nicht geholfen. Scheint mir mit der Kodierung zusammen zu hängen.

Ich habe mal von einer Tabelle Screens angelegt.

Report-Vorschau

Report.png (52.61 KiB) 3153 mal betrachtet

[shokwave]

Sieht aus, als wäre die Spalte Bezeichnung mit Base64 codiert. Kann das sein?

[MacWomble]

Ich habe keine Ahnung, wo ich die Kodierung umgestellt haben sollte. Die Datenbank habe ich angelegt, wie alle anderen auch (und diese funktionieren) - ausserdem werden die Daten in der Datenvorschau ja auch richtig angezeigt.

Ich habe einfach eine Tabelle angelegt und die Datensätze eingetippt. Kann also auch nichts mit den Daten rein gekommen sein.

Code: Alles auswählen

CREATE TABLE "Abteilung" (
	"ID"	INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE,
	"Bezeichnung"	TEXT,
	"FlukeNr"	INTEGER
)

[gladio]

Kannst du das Verhalten auch mal mit z.B. Lazreport testen?
Wenn das da nicht auftritt, kannst du die Fehlerquelle Datenbank ausschließen.

Hat vielleicht nichts damit zu tun:
Warum ist das Feld 'Bezeichnung' als TEXT definiet und nicht als VARCHAR() ?
Sieht nicht so aus als ob da ein unendlich langer Text rein soll.

[MacWomble]

Text, weil ich mit dem SQLite-Browser keine andere Auswahl habe ...

Each column in an SQLite 3 database is assigned one of the following type affinities:

TEXT
NUMERIC
INTEGER
REAL
BLOB

Mit Lazreport muss ich mal versuchen. Es irritiert mich halt, dass es gerade mit dieser einen Datenbank auftritt, nicht mit den anderen ...

[charlytango]

Text, weil ich mit dem SQLite-Browser keine andere Auswahl habe ...

Mit HeidiSQL kann man Varchar als Feldtyp auswählen und bei DB Browser for SQLite zeigt das Dropdown zwar die 5 Typen zur Auswahl, man kann aber zB "varchar(30)" einfach direkt ins Dropdown-Feld rein schreiben und das wird auch so akzeptiert.
Wohlgemerkt - unter Windows. Ob es das unter Linux auch gibt weiß ich nicht. Doch vielleicht klappt es einfach indem man den gewünschten Typ direkt ins Feld rein schreibt.

[MacWomble]

Das kann ich gerne testen - Danke.

Nachtrag:

Tatsächlich löst dein Tipp mein Problem. Ich habe jetzt VarChar(30) eingetragen und es wird nun richtig angezeigt. Erklärbar ist mir das ganze jedoch nicht, da es ja mit anderen Datenbanken funktioniert,

Jedenfalls vielen Dank für die Hilfen!

[Ich934]

Tatsächlich löst dein Tipp mein Problem. Ich habe jetzt VarChar(30) eingetragen und es wird nun richtig angezeigt. Erklärbar ist mir das ganze jedoch nicht, da es ja mit anderen Datenbanken funktioniert,

Ich vermute mal, fpreport hat ein Problem mit dem typeless von SQLite. SQLite kennt intern nur fünf Datentypen. Das sind die oben genannten die zu auswählen kannst. Mehr gibt es erst mal nicht und mehr verwendet SQLite nicht. Das Problem hierbei ist, dass dann z.B. ein kurzer Text auch als "TEXT" und somit als "(MEMO)" zurück kommt und entsprechend behandelt werden muss. Entweder man macht ein Type-Casting oder arbeitet direkt mit dem Memo-Werten (Zahlen etc. dann analog).

SQLite versteht auch andere Werte (z.B. VARCHAR) und wandelt diese dann intern auf die eigenen Datentypen um. Das ist gedacht, um zum einen eine Migration von/zu einer anderen Datenbank zu erleichtern und zum anderen um auch die Absicht der Speicherung besser zu dokumentieren. Also du als Entwickler kannst damit verdeutlichen, dass es sich um eine 20-stelliger Zeichenkette handelt wenn du VARCHAR(20) verwendest, obwohl intern dann wieder TEXT verwendet wird.

fpreport hat eventuell einfach ein Problem mit dem Memo-Wert und stellt diesen so "verhunzt" dar. Warum allerdings Base64-kodiert ist schon etwas komisch, aber gut, ich verstehe auch nicht alles.

Quellen:
Datatypes in SQLite Version 3, 3. Type Affinity
Datatypes In SQLite Version 2, 1.0 Typelessness