fb 2.5 von utf8 umstellen zu win1252

[Kostas]

Hallo Zusammen,

die Frage vorab: suche ein tool um eine FB-DB komplett von utf8 auf win1252 umzustellen.

Meine DB ist als utf8 angelegt. Eigentlich würde Win1252 völlig reichen da nur Deutsche Inhalte vorkomme.
Jetzt muss ich aus einer Access DB eine Tabelle importieren die 79 Felder beinhaltet.
76 Felder davon sind Strings mit einer Länge von 255 Zeichen. Die meister Felder davon
wie Mengeneinheit haben deutlich kürzere Inhalte. Da die Access Datenbank immer wieder
zum importieren verwendet wird und keine Felddefinitionen bekannt sind, muss ich
die Feldlängen 1:1 übernehmen.
Meine DB ist jedoch in utf8, somit ist die Recordlänge mit Size = 73638 zu lang für FB.
Also habe ich eine neue Domain angelegt

Code:

CREATE DOMAIN AS255 AS
VARCHAR(255) CHARACTER SET WIN1252
COLLATE WIN1252;

Danach konnte ich die Tabelle mit allen 79 Feldern anlegen.

Ich dachte, damit habe ich gewonnen. Jetzt möchte ich mit IBO darauf zugreifen und bekomme
auch den Hinweis dass der Record zu lang ist. Ich vermute IBO geht auf das Default character set
welches eben utf8 ist.

Nachdem die komplette DB eh nur Deutsche Inhalte hat, könnte ich doch die DB von utf8 in win1252
konvertieren. Kennt jemand so ein tool das des macht? Ich gehe nicht davon
aus dass man einfach

Code:

alter character set

alles umgestellt bekommt. Alle Tabellen und Felder
müssen vermutlich manuell umgestellt werden.

Gruß Kostas

[Bernhard Geyer]

Wie kommst du genau auf 73638?
Mit 76*255*3 bin ich weit darunter.

Zitat:

Da die Access Datenbank immer wieder zum importieren verwendet wird und keine Felddefinitionen bekannt sind, ...

Wie wäre es sich die Felddefinitionen (bzw. die Bedeutung der Felder) heraus zu suchen.
Wenn du schon weißt das viele kleiner sind, lege sie halt in FB kürzer an.

[mkinzler]

Was spricht gegen Normalisierung?

[IBExpert]

Neben der Tatsache, das eine Umstellung der DB mit IBExpert sehr einfach geht (tools-extract metadata-alle objekte und alle daten auswählen, im resultierenden script dann einfach oben UTF8 durch win1252 ersetzen und wieder ausführen), glaube ich kaum, das beim Import von access immer 255 Zeichen lange Daten pro Spalte kommen werden, das klingt nach "Ich nehm mal 255, wird schon reichen ..". Die Feldlängen kannst du sicherlich empirisch auf das runterbrechen, was in den Importen schon drin war und ggf dafür sogar noch 100% draufpacken.

Wenn dir wirklich nichts besseres einfällt, bau dir für den Import eine Tabelle mit 76 Spalten "Blob Sub_type text". Die belegen in Bezug auf die Datensatzbreite 8 Byte pro Spalte, damit kannst du zur Not auch 5000 Spalten anlegen, wenn die sinnvolle Feldnamen einfallen, die dann nicht das 32k Limit der Metadatendefinition erreichen.

Das als Anlass zu nehmen, die Datenbank von utf8 wieder auf win1252 umzustellen, halte ich für eine "unglückliche" Entscheidung, irgendwann sind im Import 250 Spalten der Länge 500 oder was auch immer, dann kommt irgendwann das nächste Limit, welches auch immer.

Oder mach dir die Mühe, den Access kram erst mal in ein Format wie csv zu exportieren und beginne damit ...

[Bernhard Geyer]

Zitat:

Zitat von IBExpert (Beitrag 1264634)

..., glaube ich kaum, das beim Import von access immer 255 Zeichen lange Daten pro Spalte kommen werden, das klingt nach "Ich nehm mal 255, wird schon reichen ..".

Nicht mal das. 255 ist die Defaultlänge für einen kurzen String.

[Kostas]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1264619)

Wie kommst du genau auf 73638?
Mit 76*255*3 bin ich weit darunter.

Zitat:

Da die Access Datenbank immer wieder zum importieren verwendet wird und keine Felddefinitionen bekannt sind, ...

Wie wäre es sich die Felddefinitionen (bzw. die Bedeutung der Felder) heraus zu suchen.
Wenn du schon weißt das viele kleiner sind, lege sie halt in FB kürzer an.

Die Größe lieferte mit IBExpert. Ist utf8 nicht 4 Byte lang?
Es handelt sich um GEAB Importdateien. Die Dateien das sind Leistungsverzeichnisse im Bauwesen. Es gibt mehrere Version die sich
auch unterscheiden. Ich habe ein Importprogramm eingekauft welches diese GEAB Dateien importiert und in einer Access Datei ablegt.
Leider werden hierbei alle String Felder mit einer Länge von 255 Zeichen angelegt. GEAB ist schon definiert doch die Umsetzung in
Access differiert. Das Programm fasst bestimmte Felder zusammen. Ich habe den Hersteller schon kontaktiert, aber ich fürchte dass
es schwierig sein wird die Feldlänger zu benennen.

Gruß Kostas

[Kostas]

Zitat:

Zitat von mkinzler (Beitrag 1264632)

Was spricht gegen Normalisierung?

Genau diesen Weg gehe ich gerade. :-)

[Kostas]

Zitat:

Zitat von IBExpert (Beitrag 1264634)

Neben der Tatsache, das eine Umstellung der DB mit IBExpert sehr einfach geht (tools-extract metadata-alle objekte und alle daten auswählen, im resultierenden script dann einfach oben UTF8 durch win1252 ersetzen und wieder ausführen) ...

Hallo Holger,

habe ich das richtig verstanden:
Die DB öffnen, Extract Metadate, Alle Meta Objekte, alle Tabellen, unter Optionen Extract Blobs, jetzt das script ausführen.
Es wird ein script mit Metadaten und Daten generiert. Das neue script öffnen, in allen Metadata die Vorkommnissen UTF8 durch WIN1252
ersetzen und das Script ausführen. Alle Felder incl, Memo werden von UTF8 in WIN1252 konvertiert.


Wenn die DB zu groß ist, müsste ich die Metadaten ohne Daten exportieren und die Daten separat exportieren. Würde das funktionieren?

Gruß Kostas

[Edit] So hat es leider nicht funktioniert. Die Feldinhalte sind nicht konvertiert.

[mkinzler]

Zitat:

Ist utf8 nicht 4 Byte lang?

Nein, variabel zwischen 1 und 4. ASCI-Zeichen belegen nur 1 Zeichen.

[himitsu]

Ja, aber viele DBMS machen es sich einfach mit der Speicherverwaltung und nehmen 3 oder 4 Byte pro "UTF-8"-Char, als Datenbreite für das jeweilige Feld.
1 bis 3 Byte pro Char, für den UCS-2-Bereich und der vollte Unicode-Bereich benötigt bis zu 4 Byte.

Ach ja, mit normalisieren war nicht das Charset gemeint, sondern die Tabellenstruktur,
also die vielen Spalten auf mehrere Tabellen aufteilen und Gleiches zusammenzufassen.


Warum willst du denn an dieser Stelle rumschrauben?
- Speicherplatz auf der Festplatte? (ok)
- aber dei der Übertragung sollten die DBMS doch intelligenter sein und ungenutzten Speicherplatz nicht mit übertragen
- ansonsten kann man bestimmt auch gut eine Komprimierung in den Datenverkehr einschalten, welche die leeren Bereiche quasi weglässt.
- Und außerdem kann man die Daten auch in einer anderen Codierung übertragen, als wie sie in der DB stehen? (z.B. als UTF-8 in der DB belassen und die Connection auf Win1252 umstellen)




Daten ohne Tabellenformat exportieren,
die Tabellen oder gleich die ganze Datenbank mit dem gewünschten Charset neu erstellen
und dann die Daten wieder importieren.

[Kostas]

Zitat:

Zitat von himitsu (Beitrag 1264691)

Ach ja, mit normalisieren war nicht das Charset gemeint, sondern die Tabellenstruktur,
also die vielen Spalten auf mehrere Tabellen aufteilen und Gleiches zusammenzufassen. ....

Das ist klar, genau das habe ich bereits umgesetzt. Zusätzlich habe ich die Felder einfach gekürzt und konnte testweise die Tabellen anlegen.

Zitat:

Zitat von himitsu (Beitrag 1264691)

Warum willst du denn an dieser Stelle rumschrauben? ....

Das Problem ist, Firebird hat eine Recordlängenbeschrenkung. Ich habe versucht die Tabelle 1:1 mit allen String Feldern varchar(255)
anzulegen und hab eine Fehlermeldung bekommen das der Record mit einer Länge von 73638 zu lange sei. Das hat sicherlich mit utf8 zu tun.

Ich habe jetzt meine DB bei utf8 belassen und die Felder entsprechend gekürzt. Eine gewisses Restrisiko ist dennoch da da ich nicht
zuverlässig sagen kann was ich für Daten bekommen werde. Bei Felder wie PLZ habe ich einfach varchar(10) gemacht und nicht varchar(255)
bei NAMEAUFTRAGGEBER varchar(100) anstelle varchar(255) sollte reichen.
Um diese Gefahr einzudämmen, prüfe ich die Datenlänge mit der entsprechenden Feldlänge.


Gruß Kostas

[mkinzler]

Oder nimm TextBlobs ( wie schon vorgeschlagen) dann kann jedes Feld bis zu 32KB groß sein und trotzdem wie ein (Var)Char-Feld angessprochen werden.

[Kostas]

Irgendwie stellen sich mit die Nackenhaare bei dem Gedanken in einer Tabelle 76 Memofelder zu haben :-)
Bedingt durch FB1.5 Erfahrungen meide ich Memofelder so gut wie es geht. Zu Anfangszeit von FB1.5 gab es
massive Probleme mit Memos. Vermutlich gibt es jetzt keine Probleme damit.

Gruß Kostas

[mkinzler]

Nein, bis zu einer Größe von 32KB kann man diese wie VarChar-Felder durchsuchen.

[IBExpert]

Zitat:

Zitat von Kostas (Beitrag 1264644)

habe ich das richtig verstanden:
Die DB öffnen, Extract Metadate, Alle Meta Objekte, alle Tabellen, unter Optionen Extract Blobs, jetzt das script ausführen.
Es wird ein script mit Metadaten und Daten generiert. Das neue script öffnen, in allen Metadata die Vorkommnissen UTF8 durch WIN1252
ersetzen und das Script ausführen. Alle Felder incl, Memo werden von UTF8 in WIN1252 konvertiert.
Wenn die DB zu groß ist, müsste ich die Metadaten ohne Daten exportieren und die Daten separat exportieren. Würde das funktionieren?

Wenn deine daten kompatibel sind, dann wir das genau so gehen. Du must ein format auswählen,bei dem auch blobs unterstützt werden
(am besten seperate files oder file) und bei den optionen alles sinnvolle einstellen

[Kostas]

Danke Holger,

werde ich nochmals ausprobieren. Mein erster schneller Test hat nicht funktioniert.
Auf dem ersten Blick funktionierte es so- ob es richtig weis ich nicht:
Metadata Extract, Alle Metadaten, alle Daten, Blobs exportieren. Jetzt sehe ich das IBEBlock
script und ersetze Names=UTF8 in Names=WIN1252.
Das IBEBlock wird nun ausgeführt. Jetzt öffne ich das Script welches Metadaten und Daten enthält
und ersetze alle Vorkommnisse UTF8 durch WIN1252. Danach lasse ich auch dieses Script laufen.
Auf den ersten Blick ist die DB umgestellt und alle Feldinhalte sind sauber konvertiert.

Für meine Fall ist das nicht mehr notwendig da ich die Felder gekürzt habe und die DB ist bei UTF8 geblieben.
Dennoch ist es schön zu wissen wie es mit IBExpert funktioniert.

Danke Holger.
Dir noch eine schöne Zeit.

Gruß Kostas