Umlaute in Feldnamen werden nicht importiert - bricht ab

[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