Migration OEM ---> ANSI

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Antworten
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Migration OEM ---> ANSI

Beitrag von ramses »

Hi

angedacht ist die gesamten APPS von OEM nach ANSI zu konvertieren.

Gibt es dazu evtl. ein Tool zur ümstellung des Quellcodes, Datenbanken und Text-Files der gesamten App.?

Oder ist hier Handarbeit angesagt?

Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: Migration OEM ---> ANSI

Beitrag von HaPe »

Hallo Carlo !
angedacht ist die gesamten APPS von OEM nach ANSI zu konvertieren.
Gibt es dazu evtl. ein Tool zur ümstellung des Quellcodes, Datenbanken und Text-Files der gesamten App.?
Hmm :?:
Je nachdem wie viele PRGs, Tabellen und Text-Files umzusetzen sind:
- Für nicht gaaanz so viele Dateien würde ich meinen Semware-Editor drauf ansetzen, alle PRGs und Textdateien eines Projektes laden und mittels Semware-Script die Zeichen ersetzen (dazu habe ich zwei Scripte/Makros die Umlaute im DOS-Text in Windows-Text bzw. andersrum umsetzen). Für Tabellen habe ich auch ein DBF-Makro welches zur Bearbeitung im Editor den "Header wegschnippelt" und die Daten zeilenweise anzeigt. Beim Speichern wird der Header wieder davorgesetzt und ferddisch. Damit müsste man jedoch alle DBFs einzeln laden und durchnudeln.
- Für viele Dateien würde ich was Programmieren das anhand der Datei-Endungen die kompletten Verzeichnisse des Projektes durchläuft und ersetzt. Bei den Tabellen muß man den "Header" dabei überspringen was etwas aufwendiger ist.
--
Hans-Peter
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Migration OEM ---> ANSI

Beitrag von ramses »

Hallo Hans-Peter

es sind nicht nur die PRG und anderen Dateien im Project sondern auch alle bei den Kunden. Also sehr sehr sehr viele Dateien. ....

Ich zweifle inzwischen ob die Umstellung auf "All ANSI" eine gute Idee ist.....


Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Migration OEM ---> ANSI

Beitrag von brandelh »

die DBFNTX Dateien bleiben ja immer auf OEM,
Bei FOXDBF ist das von der EXE Einstellung abhängig.
Für unsere Breiten sind die Daten meist nicht das Problem, ich habe nur meine EXE umgestellt, damit ich die Systemaufrufe und die Textanzeigen im Programm ohne Umsetzung erhalten habe (dabei hatte ich ab und an ein Problem). Falls man jedoch tatsächlich osteuropäische oder noch exotischere Zeichen unterstützen muss, ist eine ANSI Umsetzung nicht ausreichend, hier sollte man sich überlegen die Texte gleich in UTF8 (OEM DBF) zu speichern. Falls man nicht gleich einen SQL Server mit Unicode verwendet.
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Migration OEM ---> ANSI

Beitrag von Tom »

FOX kann man relativ leicht aktualisieren. Wie Hubert schrieb: Der Modus einer neu erzeugten (!) Tabelle ist von den OEM/ANSI-Einstellungen beim Erzeugen abhängig. Also: App auf ANSI umschalten, Tabellen neu erzeugen, Inhalte aus den bestehenden einlesen, fertig. DBFNTX bleibt sowieso immer auf OEM, und es wird IMMER umgesetzt, ganz egal, wie der Schalter steht, weil intern sowieso mit ANSI gearbeitet wird.

Quellcodes kann man eigentlich in OEM lassen, wenn sie da sind (Compilerschalter). Oder man schreibt einen Dreizeiler: Alle PRG einlesen und mit ConvToAnsiCp() einfach wieder durchschreiben. Ich habe dafür FileStr() und StrFile() aus den Tools verwendet.

Ansonsten muss man nur alle Konvertierungsfunktionen abfangen, die man z.B. für die Kommunikation mit DLLs oder das Erzeugen von Schnittstellendateien verwendet, meistens ja ConvToAnsiCP() und Brüder - oder UFT-Konvertierungen zum Beispiel aus Pablos Bibliothek. Die können eigentlich fast alle raus, weil eigentlich niemand mehr OEM braucht.

Wer data driven arbeitet, sollte natürlich auch seine in Tabellen ausgelagerten Codeblöcke usw. prüfen.

Alles in allem aber nicht viel mehr als ein Tag Arbeit, höchstens.
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Migration OEM ---> ANSI

Beitrag von ramses »

Hallo Tom

danke für deine Ausführungen. Nach einigem Experimenten habe ich die Idee der Umstellung auf ANSI wieder verworfen. Die Probleme waren zu gross.

Vieles hat nicht mehr funktioniert es war ein Schritt ins Chaos.
Es ist einfacher das Personal zu instruieren einen bestimmten Editor für die wenigen Anpassung an Parametern zu werwenden als alles auf Ansi umzuschreiben und vorallem dann auch zu Testen um sicherzustellen dass nichts übersehen wurde.


Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Migration OEM ---> ANSI

Beitrag von AUGE_OHR »

ramses hat geschrieben: Mi, 09. Mai 2018 16:16angedacht ist die gesamten APPS von OEM nach ANSI zu konvertieren.
arbeitest du mit unterschiedlichen Sprachen / Codepage :?:
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Migration OEM ---> ANSI

Beitrag von ramses »

Hallo Jimmy

ich verwende nur deutsch/englisch. Jedoch sind in den Dateien/Programmcode viele Steuerbefehle enthalten. Wenn ich die auf Charset ANSI wechlse werden die alle natürlich auch umgestellt. Das führte beim einem Test zum Crash in allen angeschlossenen Steuerungen. Auch die Antwortstrings aus den Steuerungen sind in OEM. Eine Umstellung bringt so viel zu viel Aufwand.....

Gruss Carlo
Valar Morghulis

Gruss Carlo
Antworten