Umlaute in Feldnamen werden nicht importiert - bricht ab

[mcinternet]

Zitat von Delphi.Narium:

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

[samso]

Zitat von mcinternet:

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?

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.

[p80286]

Zitat von Delphi.Narium:

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.

[Delphi.Narium]

Zitat von p80286:

Zitat von Delphi.Narium:

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 von Delphi.Narium:

@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 von mcinternet:

Zitat von Delphi.Narium:

@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 )