ADS und Crypt Funktion aus XBT
Moderator: Moderatoren
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
ADS und Crypt Funktion aus XBT
Hallo,
ich mache grade den Versuch x mit dem ADS und komme in folgendem Punkt nicht weiter.
Eingesetzt werden umfangreiche DBF's, die zum grossen Teil Felder enthalten, die mit crpyt() verschlüsselt sind. Das stammt noch aus der schönen Zeit der Clipper5e Anwendungen.
Ich bekomme diese Felder einfach nicht mehr lesbar entschlüsselt. Das liegt irgendwie daran, dass die Crypt-Funktion Zeichen erzeugt, die in der Datenbank (in ADS) nicht gepeichert werden können.
Ich habe mal folgende Versuche gemacht. Kleines Programm mit Eingabefeld. Ich gebe eine Zeichenfolge ein und speicher sie in eine Var.
Diese Var. verschlüssel ich mit crypt. und speicher sie in ein Feld der Datenbank. Dann geht es schon los. Wenn ich mir den Inhalt der Var und den Inhalt des Feldes anzeigen lasse, gibt es schon Unterschiede. Wenn ich dieses Feld dann wieder entschlüssel, kommt nur noch Müll raus.
Wäre schön, wenn jemand dieses Problem schon mal gelöst hat und mir da weiterhelfen könnte.
Danke
Ewald
ich mache grade den Versuch x mit dem ADS und komme in folgendem Punkt nicht weiter.
Eingesetzt werden umfangreiche DBF's, die zum grossen Teil Felder enthalten, die mit crpyt() verschlüsselt sind. Das stammt noch aus der schönen Zeit der Clipper5e Anwendungen.
Ich bekomme diese Felder einfach nicht mehr lesbar entschlüsselt. Das liegt irgendwie daran, dass die Crypt-Funktion Zeichen erzeugt, die in der Datenbank (in ADS) nicht gepeichert werden können.
Ich habe mal folgende Versuche gemacht. Kleines Programm mit Eingabefeld. Ich gebe eine Zeichenfolge ein und speicher sie in eine Var.
Diese Var. verschlüssel ich mit crypt. und speicher sie in ein Feld der Datenbank. Dann geht es schon los. Wenn ich mir den Inhalt der Var und den Inhalt des Feldes anzeigen lasse, gibt es schon Unterschiede. Wenn ich dieses Feld dann wieder entschlüssel, kommt nur noch Müll raus.
Wäre schön, wenn jemand dieses Problem schon mal gelöst hat und mir da weiterhelfen könnte.
Danke
Ewald
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: ADS und Crypt Funktion aus XBT
hi,
Clipper = OEM
ADS = ANSI
so kann man kein crypt() anwenden.
gruss by OHR
Jimmy
ein Schuss aus der Hüfte :Ewald hat geschrieben: Das stammt noch aus der schönen Zeit der Clipper5e Anwendungen.
Clipper = OEM
ADS = ANSI
so kann man kein crypt() anwenden.
gruss by OHR
Jimmy
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Hallo Jimmy,
muss ich noch nachschieben: Die Datenbanken laufen schon lange mit xbase++. Dort tritt das Problem mit crypt() nicht auf. Ich habe dann heute noch mal die Daten in den Datenbanken entschlüsselt und mit dem ADS und crypt() neu verschüsselt. Dabei habe ich charset ansi eingestellt. Funktioniert etwas besser, ist aber auch nicht praxistauglich, da viel noch falsch ausgegeben wird. Ich glaube/hoffe, dass ich irgendwo einen Schalter umlegen kann. Entweder in der Konfiguration des Servers oder in den Programmen. Aber was und wo? Es ergibt sich eine für mich nicht überschaubare Anzahl von Möglichkeiten, wenn man das kombiniert. Wäre gut zu wissen, ob crypt() und ADS tatsächlich nicht zusammen laufen.
Gruß
Ewald
muss ich noch nachschieben: Die Datenbanken laufen schon lange mit xbase++. Dort tritt das Problem mit crypt() nicht auf. Ich habe dann heute noch mal die Daten in den Datenbanken entschlüsselt und mit dem ADS und crypt() neu verschüsselt. Dabei habe ich charset ansi eingestellt. Funktioniert etwas besser, ist aber auch nicht praxistauglich, da viel noch falsch ausgegeben wird. Ich glaube/hoffe, dass ich irgendwo einen Schalter umlegen kann. Entweder in der Konfiguration des Servers oder in den Programmen. Aber was und wo? Es ergibt sich eine für mich nicht überschaubare Anzahl von Möglichkeiten, wenn man das kombiniert. Wäre gut zu wissen, ob crypt() und ADS tatsächlich nicht zusammen laufen.
Gruß
Ewald
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hallo,
ich weiß (oder glaube zu Wissen), dass Crypt() nur fehlerfrei funktioniert, wenn der von Crypt verschlüsselte String in Länge und Byte unverändert, zusammen mit dem Schlüsselstring zum Entschlüsseln genutzt wird.
Eine TYP Convertierung beim Speichern, muss also 100% zurückgesetzt werden, bevor Crypt aufgerufen werden darf. Wenn ADS nicht in der Lage ist ohne Convertierung zu arbeiten (z.B. weil chr(0) nicht gespeichert werden dürfen - keine Ahnung ob das so ist ???) geht es nicht.
ich weiß (oder glaube zu Wissen), dass Crypt() nur fehlerfrei funktioniert, wenn der von Crypt verschlüsselte String in Länge und Byte unverändert, zusammen mit dem Schlüsselstring zum Entschlüsseln genutzt wird.
Eine TYP Convertierung beim Speichern, muss also 100% zurückgesetzt werden, bevor Crypt aufgerufen werden darf. Wenn ADS nicht in der Lage ist ohne Convertierung zu arbeiten (z.B. weil chr(0) nicht gespeichert werden dürfen - keine Ahnung ob das so ist ???) geht es nicht.
Gruß
Hubert
Hubert
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Code: Alles auswählen
Eingabevariable Hein Mück aus Eckernförde
Eingabevariable crypt õ©¬[XZˆ`¿—„Ymya[%/Pà]
- Rolf Ramacher
- Der Entwickler von "Deep Thought"
- Beiträge: 1931
- Registriert: Do, 09. Nov 2006 10:33
- Wohnort: Bergheim
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
hi,
zeig uns doch mal deine DBESYS.PRG
mit "charset ansi" NEU erstellte DBF per ConvToAnsiCP() übertragen ?
mit einer "reinen" ANSI DBF sollte es funktionieren, aber damit kann
Cl*pper nichts mehr anfangen ...
gruss by OHR
Jimmy
p.s. der Crypt(..., cPW) String hat doch keine Umlaute, oder ?
NTX oder CDX ? ANSI oder OEM ?Ewald hat geschrieben: muss ich noch nachschieben: Die Datenbanken laufen schon lange mit xbase++. Dort tritt das Problem mit crypt() nicht auf.
zeig uns doch mal deine DBESYS.PRG
also wieder OEM "Umlaute"Ewald hat geschrieben: Ich habe dann heute noch mal die Daten in den Datenbanken entschlüsselt
ich glaube da haben wir es. Muss man nicht die "Umlaute" in eineEwald hat geschrieben: und mit dem ADS und crypt() neu verschüsselt.
Dabei habe ich charset ansi eingestellt.
mit "charset ansi" NEU erstellte DBF per ConvToAnsiCP() übertragen ?
Code: Alles auswählen
#pragma library( "xbtbase1.lib" )
#pragma library( "xbtbase2.lib" )
PROCEDURE MAIN
LOCAL a := "Hein Mück aus Eckernförde"
LOCAL b := ConvToAnsiCP(a)
LOCAL cPW := "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
? crypt(a,cPW)
? crypt(b,cPW)
WAIT
RETURN
Cl*pper nichts mehr anfangen ...
gruss by OHR
Jimmy
p.s. der Crypt(..., cPW) String hat doch keine Umlaute, oder ?
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Code: Alles auswählen
ein Schuss aus der Hüfte :
Clipper = OEM
ADS = ANSI
ich habe mittlerweile durch Ausprobieren herausbekommen, dass ich wohl nicht mit der crypt() Funktion kämpfe, sondern mit Zeichensätzen.
Bei der Installation des ADS-Servers wird nach dem OEM Zeichensatz gefragt. Also denke ich, ADS wird auch mit charset OEM arbeiten können - oder nicht ???
Bei div. Versuchen habe ich gemerkt das der ADS Werte > chr(175) nicht so speichert, wie ich sie eingebe (oder crypt() sie erzeugt). Eine passende OEM Tabelle habe ich im ADS nicht gefunden. Setzt du den Server selbst ein ?
Gruß
Ewald
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9373
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Hallo, Ewald.
Wenn Du mit Charset OEM (Standard bei Xbase, wegen der Clipper-Kompatibilität) arbeitest, mußt Du bei der Installation der ADS beide Zeichensatzabfragen auf OEM setzen. Danach arbeitet Crypt() auch (wieder) problemlos und analog zur normalen DBFNTX. Davon abgesehen sind die Zeichensatzeinstellungen essentiell, damit Du "Mücke" zurückbekommst, wenn Du "Mücke" (auch ohne Crypt()) in einem Datenbankfeld speicherst.
Hinweis: In der ADS 8 läßt sich der Zeichensatz aus der Configuration Utility nicht ändern, obwohl es so aussieht, als würde es gehen. Es gibt ein Tool dafür, aber es ist fast einfacher, die ADS neu aufzusetzen.
Wenn Du mit Charset OEM (Standard bei Xbase, wegen der Clipper-Kompatibilität) arbeitest, mußt Du bei der Installation der ADS beide Zeichensatzabfragen auf OEM setzen. Danach arbeitet Crypt() auch (wieder) problemlos und analog zur normalen DBFNTX. Davon abgesehen sind die Zeichensatzeinstellungen essentiell, damit Du "Mücke" zurückbekommst, wenn Du "Mücke" (auch ohne Crypt()) in einem Datenbankfeld speicherst.
Hinweis: In der ADS 8 läßt sich der Zeichensatz aus der Configuration Utility nicht ändern, obwohl es so aussieht, als würde es gehen. Es gibt ein Tool dafür, aber es ist fast einfacher, die ADS neu aufzusetzen.
Herzlich,
Tom
Tom
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Hallo Tom,
schön von dir zu hören. Damit wäre ich dann wieder am Anfang meiner Frage nach den Schaltern (siehe oben) gelandet.
Der Knackpunkt ist wohl folgender: Ich teste hier mit einer Version 6.2, die mir bei der Installation nur 2. Abfragen anbietet.
1. Ansi
-default to machine- (hier kann ich dann weitere Länder wählen.)
aber nichts mit OEM
2. OEM
-default USA- (hier kann ich dann auch weitere Länder wählen.
Zwei Abfragen nach OEM gibt es nicht. Ob das an der Version liegt ???
Gruß
Ewald
schön von dir zu hören. Damit wäre ich dann wieder am Anfang meiner Frage nach den Schaltern (siehe oben) gelandet.
Der Knackpunkt ist wohl folgender: Ich teste hier mit einer Version 6.2, die mir bei der Installation nur 2. Abfragen anbietet.
1. Ansi
-default to machine- (hier kann ich dann weitere Länder wählen.)
aber nichts mit OEM
2. OEM
-default USA- (hier kann ich dann auch weitere Länder wählen.
Zwei Abfragen nach OEM gibt es nicht. Ob das an der Version liegt ???
Gruß
Ewald
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9373
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Hallo, Ewald.
Ich habe gerade meinen Code durchstöbert und festgestellt, daß ich diesem Problem selbst begegnet bin: Aufgrund der OEM <-> ANSI <-> OEM-Konvertierung (Xbase speichert sonst alle Tabellendaten direkt im OEM-Schriftsatz, deshalb geht es bei DBFNTX) zerbröseln sich die Feldinhalte. Ich fange Crypt() bei ADS ab und speichere statt des gecrypteten Textes dann einen Hex-String, also StrToHex bzw. HexToStr eingebettet in die Crypt-Funktionen. Wenn die ADS erstmals in Betrieb genommen wird und Daten vorgefunden werden, die offenbar keine Hex-Strings sind, öffne ich die Tabellen einmalig per DBFNTX und schreibe nach Hex durch. Sorry dafür, daß ich damit nicht vorher gekommen bin. Es wird kaum einen anderen Weg geben; man kann bei CharSet OEM und ADS schon froh sein, daß Umlaute erhalten bleiben.
Ich habe gerade meinen Code durchstöbert und festgestellt, daß ich diesem Problem selbst begegnet bin: Aufgrund der OEM <-> ANSI <-> OEM-Konvertierung (Xbase speichert sonst alle Tabellendaten direkt im OEM-Schriftsatz, deshalb geht es bei DBFNTX) zerbröseln sich die Feldinhalte. Ich fange Crypt() bei ADS ab und speichere statt des gecrypteten Textes dann einen Hex-String, also StrToHex bzw. HexToStr eingebettet in die Crypt-Funktionen. Wenn die ADS erstmals in Betrieb genommen wird und Daten vorgefunden werden, die offenbar keine Hex-Strings sind, öffne ich die Tabellen einmalig per DBFNTX und schreibe nach Hex durch. Sorry dafür, daß ich damit nicht vorher gekommen bin. Es wird kaum einen anderen Weg geben; man kann bei CharSet OEM und ADS schon froh sein, daß Umlaute erhalten bleiben.
Herzlich,
Tom
Tom
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Hallo Tom,
ich habe es auch mit charset to ansi versucht. Vorher die DBF entschlüsselt und die Felder mit convtoansiCP neu eingelesen. Ging auch nicht. Mir raucht aber mittlerweile dermassen die Bime, das Anwendungsfehler nicht mehr auszuschließen sind
Es nutzt nur nichts, ich brauche ein Lösung. Gibt es eingentlich eine gestandene Alternative zum ADS ?
Es gefällt mir schon nicht, dass die crypt() Funktion aus den Tools stammt und nicht aus xbase++ selbst. Wenn es gelingen sollte, mit AX-encrypt zu verschlüsseln, sehe ich schon die Situation kommen, das aus irgendwelchen heute noch nicht zu erahnenden Gründen (ein Update von Xbase oder ADS oder Win oder ein Hardwarewechsel oder weiß der Geier was) die Daten leider nicht mehr (problemlos) zurückgeschlüsselt werden können.
Dem möchte ich mich eigentlich nicht ausliefern ...
Gruß
Ewald
ich habe es auch mit charset to ansi versucht. Vorher die DBF entschlüsselt und die Felder mit convtoansiCP neu eingelesen. Ging auch nicht. Mir raucht aber mittlerweile dermassen die Bime, das Anwendungsfehler nicht mehr auszuschließen sind
Es nutzt nur nichts, ich brauche ein Lösung. Gibt es eingentlich eine gestandene Alternative zum ADS ?
Es gefällt mir schon nicht, dass die crypt() Funktion aus den Tools stammt und nicht aus xbase++ selbst. Wenn es gelingen sollte, mit AX-encrypt zu verschlüsseln, sehe ich schon die Situation kommen, das aus irgendwelchen heute noch nicht zu erahnenden Gründen (ein Update von Xbase oder ADS oder Win oder ein Hardwarewechsel oder weiß der Geier was) die Daten leider nicht mehr (problemlos) zurückgeschlüsselt werden können.
Dem möchte ich mich eigentlich nicht ausliefern ...
Gruß
Ewald
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hi,
die XbToolsIII sind von Alaska. Deshalb würde ich mir keine Sorgen machen
Die Probleme liegen im leidigen OEM/ANSI Umsetzungsproblem. Man sieht halt nicht ob es noch OEM schon ANSI oder schon wieder Schrott ist (als PC-Programm).
Unter Windows wird man erst dann Ruhe haben, wenn man komplett auf ANSI umstellt. D.H. aber auch den Quellcode komplett in ANSI eintippen, FOXCDX statt DBFxxx ....
die XbToolsIII sind von Alaska. Deshalb würde ich mir keine Sorgen machen
Die Probleme liegen im leidigen OEM/ANSI Umsetzungsproblem. Man sieht halt nicht ob es noch OEM schon ANSI oder schon wieder Schrott ist (als PC-Programm).
Unter Windows wird man erst dann Ruhe haben, wenn man komplett auf ANSI umstellt. D.H. aber auch den Quellcode komplett in ANSI eintippen, FOXCDX statt DBFxxx ....
Gruß
Hubert
Hubert