Migration OEM ---> ANSI
Moderator: Moderatoren
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Migration OEM ---> ANSI
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
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
Gruss Carlo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Migration OEM ---> ANSI
Hallo Carlo !
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.
Hmmangedacht 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.?
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
Hans-Peter
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Migration OEM ---> ANSI
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
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
Gruss Carlo
- brandelh
- Foren-Moderator
- Beiträge: 15706
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Migration OEM ---> ANSI
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.
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
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Migration OEM ---> ANSI
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.
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
Tom
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Migration OEM ---> ANSI
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
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
Gruss Carlo
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Migration OEM ---> ANSI
arbeitest du mit unterschiedlichen Sprachen / Codepage
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Migration OEM ---> ANSI
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
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
Gruss Carlo