Umlaute in Feldnamen werden nicht importiert - bricht ab

[tshubaka]

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

Grüsse

[mcinternet]

Zitat von tshubaka:

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 von 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.

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 von 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

Dem kann ich mich nur anschließen.

[himitsu]

Zitat von Sherlock:

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.



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.

[mcinternet]

Zitat von 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

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

Beste Grüße

mcinternet