Umlaute in Feldnamen werden nicht importiert - bricht ab

[mcinternet]

Hallo die Gemeinde,

auf einmal klappt was nicht mehr, was bisher immer funktionierte: Ein größerer Import einer Produktivdatenbank, welche auf einem Linux-System läuft. Diese ist etwas älter. Damit komme ich mit der MySQL-Workbench nicht drauf. Sie ist wohl zu alt. (Zugangsdaten stimmen, mit Delphi Rio komme ich lesend - schreibend will ich gar nicht! - dran).

hier einmal der Code, der beim Export rauskommt: - dort finde ich ein Feld mit Umlaut im Namen (was bisher kein Problem war). => Am_Prüffrequ

Code:

Code:

CREATE TABLE `ARBEITSPLSOLLMASS` (
  `ID` int(11) NOT NULL auto_increment,
   ...<snip>...
  `Am_Prüffrequ` varchar(10) NOT NULL default 'PA04',
  ...<snip>...
  PRIMARY KEY  (`ID`),
  KEY `idx_Art_AG` (`Am_Artikelnr`,`Am_Agang`),
  KEY `idx_prBez` (`Am_Agang`,`Am_Artikelnr`,`Am_Bezeichnung`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

ich habe nun Test-DBs erstellt, welche folgende Zeichensätze können:

utf8mb4
latin1
latin1_german2_ci

bei allen bricht der Import mittels Workbench und auch per Delphi ab.
Auch werden nach dem Import die Umlaute in den Feldern nicht mehr korrekt dargestellt. Mein Entwicklungsrechner (Hyper-V VM) hat sich nicht verändert.

Vielleicht hat ja jemand von Euch eine Idee?

beste Grüße aus dem Odenwald

mcinternet

[tshubaka]

Hallo,
ich benutze nie Umlaute, versuche mal ein ü auf der englischen tastatur zu finden?
auch alle unsere E_Mail Adressen sind ohne Umlaute!
aus Müller wird Mueller

Grüsse

[mcinternet]

Zitat:

Zitat von tshubaka (Beitrag 1464465)

Hallo,
ich benutze nie Umlaute, versuche mal ein ü auf der englischen tastatur zu finden?
auch alle unsere E_Mail Adressen sind ohne Umlaute!
aus Müller wird Mueller

Grüsse

Das ist leider die Antwort, die ich nicht gebrauchen kann. Denn das Produktivsystem läuft seit 20 Jahren damit und das neue System muss auch damit laufen.

beste Grüße

mcinternet

[tshubaka]

Versuche mal das Am_Prüffrequ in [Am_Prüffrequ] zu ändern.

Grüsse

[mcinternet]

Zitat:

Zitat von tshubaka (Beitrag 1464468)

Versuche mal das Am_Prüffrequ in [Am_Prüffrequ] zu ändern.

Grüsse

Bringt nix, zudem werden weit über 100 Tabellen exportiert und ins Entwicklungssystem importiert. Ich kann da nicht alles händisch korrigieren. Der Import muss automatisch so durchlaufen. Es geht nicht nur um ein Feld, sondern auch um die ganzen Beziehungen der Tables untereinander.

Gruss

mcinternet

[Delphi.Narium]

Gibt's beim Abbruch denn den Ansatz einer Fehlermeldung?

Wenn ja, wie lautet die?

[himitsu]

Das Encoding (CHARSET) der Tabelle passt ja schonmal,
aber wie sieht es mir dem DefaultEncoding der Datenbank aus und vorallem dem Encoding für die Connection.

Auch zu beachten, wenn die Dateien kein BOM besitzen und z.B. beim Importtool nichts Abweichendes explizit angegeben wurde,
dann wird im Windows meistens ANSI benutzt, aber im Linux wird oft UTF-8 genommen.

Dieses ANSI-Char als Byte würden dann ein "ungültiges" Byte für einen UTF-8-Char ergeben.

Für ANSI gibt es keinen BOM.
Tipp: SQL-Dateien besser immer als UTF-8 speichern, oder anschließend konvertieren.
Ich würde da zwar UTF-8 mit BOM empfehlen, wenn es keine Probleme gibt, aber blöder Weise kommen manche SQL-Tools im Linux mit BOM nicht klar (erkennen es dann als Zeichen, welches es zwar auch ist, aber das eigentlich beim Import entfernt/ignoriert werden sollte).

[mcinternet]

Zitat:

Zitat von Delphi.Narium (Beitrag 1464471)

Gibt's beim Abbruch denn den Ansatz einer Fehlermeldung?

Wenn ja, wie lautet die?

ERROR 1300 (HY000) at line 191992: Invalid utf8 character string: 'Am_Pr\xFCffrequ'

Operation failed with exitcode 1
13:50:16 Import of D:\Projekte\Neuentwicklung\bin\Win64\Release\dumpc ompleteexport.sql has finished with 1 errors

beste Grüße

mcinternet

[mcinternet]

Zitat:

Zitat von himitsu (Beitrag 1464472)

Das Encoding (CHARSET) der Tabelle passt ja schonmal,
aber wie sieht es mir dem DefaultEncoding der Datenbank aus und vorallem dem Encoding für die Connection.

Auch zu beachten, wenn die Dateien kein BOM besitzen und z.B. beim Importtool nichts Abweichendes explizit angegeben wurde,
dann wird im Windows meistens ANSI benutzt, aber im Linux wird oft UTF-8 genommen.

In der Connection ist KEIN Charset angegeben.

Ich verfolge da jetzt mal den Ansatz und teste.

Gruss

mcinternet

[Sherlock]

Off-Topic: Hast Du wenigstens schon das Kreuz parat, an dem der abenteuerlustige Mensch fachmännisch befestigt werden kann, der sich überlegt hat, Umlaute seien eine feine Sache als Feldname? Ich würde nichtmal heute in Delphi auf die Idee kommen, Umlaute als Bezeichner zu verwenden, und dabei geht das schon seit mindestens 10 Jahren.

Sherlock

[alex517]

Zitat:

Zitat von Sherlock (Beitrag 1464512)

Off-Topic: Hast Du wenigstens schon das Kreuz parat, an dem der abenteuerlustige Mensch fachmännisch befestigt werden kann, der sich überlegt hat, Umlaute seien eine feine Sache als Feldname? Ich würde nichtmal heute in Delphi auf die Idee kommen, Umlaute als Bezeichner zu verwenden, und dabei geht das schon seit mindestens 10 Jahren.

Sherlock

Dem kann ich mich nur anschließen.

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1464512)

und dabei geht das schon seit mindestens 10 Jahren

Dabei ist es witzig sein Program damit aufzuwerten.
Bei über 20 Tausend möglichen Zeichen, kannst jedem Bezeichner (Typen/Klassen, Properties, Variablen, Konstanten und Funktionsnamen) je ein Zeichen geben ... chinesisch bietet sich besonders an.

Schon ist dein Code schön kurz und extrem übersichtlich. :zwinker:



obfuscation

[Jasocul]

Das kommt mir soooo bekannt vor. Ich habe mit so einer Datenbank auch zu tun. Leider gehören die zu einer externen Anwendung und ich kann da nichts beeinflussen.

Ich habe das Problem gelöst, indem ich Views erstellt habe, die die Feldnamen in einen brauchbaren Namen umsetzen. Das könnte hier vielleicht auch ein Ansatz sein, wenn es keine Lösung über das Encoding gibt.

[samso]

Zitat:

Zitat von mcinternet (Beitrag 1464473)

ERROR 1300 (HY000) at line 191992: Invalid utf8 character string: 'Am_Pr\xFCffrequ'

Operation failed with exitcode 1

Das '\xFC' ist ja offensichtlich IEC 8859-1 und nicht UTF8. Ich würde also mal suchen an welcher Stelle Dein "ü" falsch kodiert wird.

[Delphi.Narium]

Der Inhalt der Fehlermeldung besagt ganz klar, dass es sich nicht um UTF8 handelt.

Und die Fehlermeldung zeigt auch, dass es sich nicht um ein Problem beim Inhalt der Datenbank handelt, sondern dass Teile des SQLs selbst nicht verstanden werden.

Wie sieht eigentlich die bemängelte Zeile 191992 im Script D:\Projekte\Neuentwicklung\bin\Win64\Release\dumpc ompleteexport.sql konkret aus?
Ist das ein Create table, ein Insert into ein wasauchimmer?

Eigentlich wäre es sehr hilfreich, wenn der Datenlieferant mal kundtuen könnte, mit welchen Optionen, welchem Zeichensatz, ... er das Script erstellt.

Weiß man dies, kann man beim Import die gleichen Einstellungen verwenden und muss nicht raten und probieren, ob und wie es klappt und hoffen, dass das auch dauerhaft so bleiben wird.

[himitsu]

@Jasocul: Was hilft dir ein View, wenn du den nicht benutzen kannst, ohne vorher die Daten in die Datenbank zu bekommen? :zwinker:

Nja, wie schon in #7 gesagt ... das Encoding beim Einlesen/Verarbeiten muß schon mit den einzulesenden Daten zusammenpassen,
entweder man kann das einstellen oder könnte vorher umkodieren.

[mcinternet]

Zitat:

Zitat von Sherlock (Beitrag 1464512)

Off-Topic: Hast Du wenigstens schon das Kreuz parat, an dem der abenteuerlustige Mensch fachmännisch befestigt werden kann, der sich überlegt hat, Umlaute seien eine feine Sache als Feldname? Ich würde nichtmal heute in Delphi auf die Idee kommen, Umlaute als Bezeichner zu verwenden, und dabei geht das schon seit mindestens 10 Jahren.

Sherlock

Der ursprüngliche Coder ist nicht mehr greifbar. Der Code stammt aus 2003 oder so.

Beste Grüße

mcinternet

[mcinternet]

So Leute, erst einmal vielen Dank für Eure rege Unterstützung. :thumb:
@himitsu brachte mich auf die richtige Idee. In der Connection fehlte das Encoding.

Witzig dabei ist: bisher hat es so funktioniert, auf einmal nicht mehr.
Nun habe ich in beiden Connections Latin1 drin und alles funzt.

Noch einmal vielen Dank und auch den Hinweis von @Sherlock werde ich aufgreifen, falls mir dieser Coder mal über den Weg läuft. :stupid:

beste Grüße aus dem schönen Odenwald

mcinternet

[himitsu]

:bounce2:
War es früher auch schon immer im Linux, oder war es da noch Windows?


Geknallt hätte es vermutlich/bestimmt ohne Umlaute in Bezeichnern, spätestens auch bei Umlauten in den Daten der Inserts. :angle:

[mcinternet]

Zitat:

Zitat von himitsu (Beitrag 1464534)

:bounce2:
War es früher auch schon immer im Linux, oder war es da noch Windows?

Die jetzige Produktionsdatenbank ist MySQL - uralt, keine Ahnung welche Version (auf jeden Fall komme ich da mit der Workbench nicht dran, dafür ist sie zu alt), läuft auf Linux und pfeift aus dem letzten Loch.
Die neue ist ne MySQL 8 und läuft auf nem Windows 2019 Server. Ich mache von dem Produktivsystem so alle Monat mal nen Export, um meine Entwicklungsdatenbank, sowie die Testumgebung auf den aktuellen Stand zu bringen. Für den Export und Import habe ich nen Automatismus gebaut, den ich in der ständigen Entwicklung pflege, damit die spätere Inproduktivnahme so glatt wie irgend möglich verläuft.

beste Grüße

mcinternet

[p80286]

Zitat:

Zitat von Delphi.Narium (Beitrag 1464520)

Eigentlich wäre es sehr hilfreich, wenn der Datenlieferant mal kundtuen könnte, mit welchen Optionen, welchem Zeichensatz, ... er das Script erstellt.

Dir ist aber klar, das Du mit dieser Anforderung mindestens 60% aller "Programmierer" vollkommen überforderst?
Das ist erst einmal nicht sooo schlimm wenn man sich dessen bewusst ist. Kriminell wird es erst, wenn "Profies" nach dem Motto arbeiten, keine Fehlermeldung alles in Ordnung. Und dann tauchen dann irgendwann verstümmelte Daten und Texte auf die sich niemand erklären kann (es waren ja die Amateure im eigenen Hause nicht an den Daten).
Ich für mein Teil traue übrigens keiner Zeichensatzangabe, sondern mache wann immer möglich eine vollständige Datenanalyse und konvertiere die Daten per Hand (wofür hab ich Delphi, da bastelt man sich was man braucht selbst). Das mag aufwendig sein, aber dann ist hinterher wenigstens alles stimmig.

Gruß
K-H

P.S.
Wer Umlaute in Feldnamen benutzt ist mit Kreuzigen noch human behandelt.

[himitsu]

Oder andersrum.

Den Praktikant die Daten importieren lassen, der importiert die Daten (z.B. UTF-8) als ANSI (ISOirgendwas), das geht alles ohne Probleme und ohne Fehlermeldungen, also alles Gut.




Aber die Umlaute in den Daten sind dann bissl kaputt.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1464516)

Zitat:

Zitat von Sherlock (Beitrag 1464512)

und dabei geht das schon seit mindestens 10 Jahren

Dabei ist es witzig sein Program damit aufzuwerten.
Bei über 20 Tausend möglichen Zeichen, kannst jedem Bezeichner (Typen/Klassen, Properties, Variablen, Konstanten und Funktionsnamen) je ein Zeichen geben ... chinesisch bietet sich besonders an.

Schon ist dein Code schön kurz und extrem übersichtlich. :zwinker:

obfuscation

<WERBUNG>
Dabei fällt mir gerade eine neue Produkt-Idee ein (Ok, von JS geklaut).

Hat jemand Interessan einem PascalMinifier, mit "security by obfuscation" ?

Warum darf das nur JS, wer könnte einen Obfuscator für Pascal-Code gebrauchen ?
Das würde doch die OpenSource-Welt revolutionieren :stupid:

Also, Bestellungen bitte an mich, die Marketing-Seite mit vielen Buzzwords ist leider gerade noch im Aufbau :oops:

</WERBUNG>

[himitsu]

Hey, ich hatte mal aus Spaße in einer OpenSource-Komponente eine unsichtbare Variable verbaut, denn einige Space-Chars sind im Unicode/Compilier nicht als Space/Puncturation markiert.

[Delphi.Narium]

Zitat:

Zitat von p80286 (Beitrag 1464545)

Zitat:

Zitat von Delphi.Narium (Beitrag 1464520)

Eigentlich wäre es sehr hilfreich, wenn der Datenlieferant mal kundtuen könnte, mit welchen Optionen, welchem Zeichensatz, ... er das Script erstellt.

Dir ist aber klar, das Du mit dieser Anforderung mindestens 60% aller "Programmierer" vollkommen überforderst?

60%?
Oh, Du unverbesserlicher Optimist ;-)

@himitsu
alt+255?

Ging auch schon zu Turbopascalzeiten (wenn ich mich recht erinnere) ;-)

Kennst Du noch die Computerzeitschrift DOS?
Da gab es mal lange Zeit 'nen Wettbewerb über eine Kilo-Mark (1024 DM) als Preisgeld.
Aufgabe war es, ein möglichst sinnvolles Programm in maximal 1024 Byte Quelltext zu packen.

Da waren dann kurze (sehr kurze) Variabel-, Funktions- ... -Namen wesentlich. Auf Leerzeichen, Zeilenumbrüche (immerhin jeweils 2 Byte) wurde verzichtet ...

Das war dann Obfuscation in Reinkultur ;-)

@mcInternet

Latin1 kommt mit 'Am_Pr\xFCffrequ' zurecht?

Kann ich mir nicht ernsthaft vorstellen. Da ist garantiert noch "irgendeine Übersetzungsstelle" dazwischen, die Dir momentan potentielle Probleme behebt. Ob das dauerhaft gutgehen wird?

Witzig wäre in dem Zusammenhang zu erfahren, ob das ü eventuell nur in diversen Anzeigetools zu sehen ist, die ein \xFC implizit bei der Anzeige übersetzen.
Nicht dass in der Quelldatenbank der Spaltenname tatsächlich 'Am_Pr\xFCffrequ' lautet und nicht, wie erwartet 'Am_Prüffrequ'.
Würde das auf jeden Fall mal prüfen, auch wenn die Idee jetzt erstmal etwas "abgefahren" klingt.

[mcinternet]

Zitat:

Zitat von Delphi.Narium (Beitrag 1464558)

@mcInternet

Latin1 kommt mit 'Am_Pr\xFCffrequ' zurecht?

Kann ich mir nicht ernsthaft vorstellen. Da ist garantiert noch "irgendeine Übersetzungsstelle" dazwischen, die Dir momentan potentielle Probleme behebt. Ob das dauerhaft gutgehen wird?

Witzig wäre in dem Zusammenhang zu erfahren, ob das ü eventuell nur in diversen Anzeigetools zu sehen ist, die ein \xFC implizit bei der Anzeige übersetzen.
Nicht dass in der Quelldatenbank der Spaltenname tatsächlich 'Am_Pr\xFCffrequ' lautet und nicht, wie erwartet 'Am_Prüffrequ'.
Würde das auf jeden Fall mal prüfen, auch wenn die Idee jetzt erstmal etwas "abgefahren" klingt.

Der kommt damit auf jeden Fall zurecht, übersetzt es auch korrekt. Ich werde es in der finalen Version der Software abstellen und mit ue arbeiten. Ich baue sowas in mein Importproggi ein. Damit sollte es dann Geschichte sein.

beste Grüße

mcinternet

[Delphi.Narium]

Zitat:

Zitat von mcinternet (Beitrag 1464559)

Zitat:

Zitat von Delphi.Narium (Beitrag 1464558)

@mcInternet

Latin1 kommt mit 'Am_Pr\xFCffrequ' zurecht?

Kann ich mir nicht ernsthaft vorstellen. Da ist garantiert noch "irgendeine Übersetzungsstelle" dazwischen, die Dir momentan potentielle Probleme behebt. Ob das dauerhaft gutgehen wird?

Witzig wäre in dem Zusammenhang zu erfahren, ob das ü eventuell nur in diversen Anzeigetools zu sehen ist, die ein \xFC implizit bei der Anzeige übersetzen.
Nicht dass in der Quelldatenbank der Spaltenname tatsächlich 'Am_Pr\xFCffrequ' lautet und nicht, wie erwartet 'Am_Prüffrequ'.
Würde das auf jeden Fall mal prüfen, auch wenn die Idee jetzt erstmal etwas "abgefahren" klingt.

Der kommt damit auf jeden Fall zurecht, übersetzt es auch korrekt. Ich werde es in der finalen Version der Software abstellen und mit ue arbeiten. Ich baue sowas in mein Importproggi ein. Damit sollte es dann Geschichte sein.

beste Grüße

mcinternet

Sorry, wenn ich da nochmal nachhake:

Zurechtkommen heißt für mich, dass es momentan geht, aber nicht das es dauerhaft geht. Da bleibt dann ein Risiko.

Für 'nen Datenbankkonvertierung, die einmalig gemacht werden muss, um System A durch System B zu ersetzen, ist das absolut ok. Für einen Dauerbetrieb nicht.

Und das Umbauen das alten System auf ein System ohne ü ... im Importproggi ist eine sehr weise Entscheidung. Hut ab. Denn sowas machen nur die wenigsten aus eigener Entscheidung (zumindest bezogen auf die Programmierer, Datenbankentwickler, ..., die ich im Laufe meines Berufslebens haben kennen lernen dürfen - daher auch meine ironische Kritik an den 60% von p80286 ;-))

[mcinternet]

Zitat:

Zitat von Delphi.Narium (Beitrag 1464560)

Zurechtkommen heißt für mich, dass es momentan geht, aber nicht das es dauerhaft geht. Da bleibt dann ein Risiko.

Für 'nen Datenbankkonvertierung, die einmalig gemacht werden muss, um System A durch System B zu ersetzen, ist das absolut ok. Für einen Dauerbetrieb nicht.

Und das Umbauen das alten System auf ein System ohne ü ... im Importproggi ist eine sehr weise Entscheidung. Hut ab. Denn sowas machen nur die wenigsten aus eigener Entscheidung (zumindest bezogen auf die Programmierer, Datenbankentwickler, ..., die ich im Laufe meines Berufslebens haben kennen lernen dürfen - daher auch meine ironische Kritik an den 60% von p80286 ;-))

Am bestehenden Produktivsystem (Delphi 7) habe ich keinerlei Chance irgendwas zu ändern. Das Ding läuft, läuft, pfeift aus dem letzten Loch. Valider compilierfähiger Quellcode ist auch nicht mehr vorhanden. Da haben später viele dran verschlimmbessert und versucht auf neuere Versionen zu heben, bis hin nach XE, was aber dann nie lief, nicht einmal, bzw. nur ein Teilen compilierfähig ist und nie produktiv ging. Es ist auch auf 1000 einzelne DLLs aufgeteilt. Somit läuft das bestehende System seit ~2003. Daher entwickle ich auf Basis der alten Formulare einen komplett neuen Unterbau. Dazu existiert meine Entwicklungsumgebung und eine Labor-/Testumgebung beim Kunden. Um eben alle Daten (es ist ein sehr spezifisches ERP-System mit bis jetzt über 110 Formularen, 330.000 Zeilen Code - das wird sich noch verdoppeln!) übernehmen zu können, habe ich ein Importprogramm gebaut, welches auch ALLE Veränderungen in der Datenbank macht. Bis jetzt sind es 133 Änderungen in der Datenbank. Damit ich das nicht alles beim Live-Gehen händisch machen muss (wäre dann auch zu fehlerbehaftet), mache ich das über dieses Import-/Konvertierprogramm, welches Bestandteil des ERP-Systemes ist: Beim Start werden Software- und Datenbankversion abgeglichen und noch bevor das Anmeldeformular erscheint, werden die notwendigen Updates gemacht. Somit sind alle Fehlerquellen ausgemerzt, da ich das ja in der Entwicklungsumgebung so teste und ansonsten nicht starten kann. Also ist der Import dann wirklich 100% fehlerfrei, da ich ja auch einmal im Monat die Daten vom Produktivsystem ziehe.

beste Grüße

mcinternet

[p80286]

Zitat:

Zitat von mcinternet (Beitrag 1464562)

Beim Start werden Software- und Datenbankversion abgeglichen und noch bevor das Anmeldeformular erscheint, werden die notwendigen Updates gemacht. Somit sind alle Fehlerquellen ausgemerzt, da ich das ja in der Entwicklungsumgebung so teste und ansonsten nicht starten kann. Also ist der Import dann wirklich 100% fehlerfrei, da ich ja auch einmal im Monat die Daten vom Produktivsystem ziehe.

Ich nehme zu Deinen Gunsten mal an, daß Du ungeschickt formuliert hast. Alleine 100% Fehlerfreihet ist schon sehr ambitioniert. Und auch die anderen Folgerungen sind doch sehr gewagt.

@Delphi.Natrium
Unverbesserlicher Optimist?? Hier lesen genug Lernwillige mit, da erreichen wir die 60% bestimmt irgendwann

Gruß
K-H

[mcinternet]

Zitat:

Zitat von p80286 (Beitrag 1464586)

Ich nehme zu Deinen Gunsten mal an, daß Du ungeschickt formuliert hast. Alleine 100% Fehlerfreihet ist schon sehr ambitioniert. Und auch die anderen Folgerungen sind doch sehr gewagt.
Gruß
K-H

Die Datenbankanpassung, sowie der Import laufen zu 100% fehlerfrei. Das gesamte System mit Sicherheit nicht.

Gruss

mcinternet