Migration OEM ---> ANSI

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Antworten
ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1088
Registriert: Mi, 28. Jul 2010 17:16

Migration OEM ---> ANSI

Beitrag von ramses » Mi, 09. Mai 2018 16:16

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

Benutzeravatar
HaPe
Foren-Moderator
Foren-Moderator
Beiträge: 546
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz

Re: Migration OEM ---> ANSI

Beitrag von HaPe » Mi, 09. Mai 2018 17:52

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

Organisator der XUG Stuttgart
Beisitzer des Deutschsprachige Xbase-Entwickler e. V.

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1088
Registriert: Mi, 28. Jul 2010 17:16

Re: Migration OEM ---> ANSI

Beitrag von ramses » Mi, 09. Mai 2018 19:55

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

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14594
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Migration OEM ---> ANSI

Beitrag von brandelh » Mi, 09. Mai 2018 21:28

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: 7333
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Migration OEM ---> ANSI

Beitrag von Tom » Do, 10. Mai 2018 9:32

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
Programmier-Gott
Programmier-Gott
Beiträge: 1088
Registriert: Mi, 28. Jul 2010 17:16

Re: Migration OEM ---> ANSI

Beitrag von ramses » Fr, 11. Mai 2018 8:57

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

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11515
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Migration OEM ---> ANSI

Beitrag von AUGE_OHR » Fr, 11. Mai 2018 21:42

ramses hat geschrieben:
Mi, 09. Mai 2018 16:16
angedacht ist die gesamten APPS von OEM nach ANSI zu konvertieren.
arbeitest du mit unterschiedlichen Sprachen / Codepage :?:
gruss by OHR
Jimmy

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1088
Registriert: Mi, 28. Jul 2010 17:16

Re: Migration OEM ---> ANSI

Beitrag von ramses » Sa, 12. Mai 2018 8:29

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

Antworten