ADS und Crypt Funktion aus XBT

[Ewald]

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

[AUGE_OHR]

hi,

Das stammt noch aus der schönen Zeit der Clipper5e Anwendungen.

ein Schuss aus der Hüfte :
Clipper = OEM
ADS = ANSI

so kann man kein crypt() anwenden.

gruss by OHR
Jimmy

[Ewald]

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

[brandelh]

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.

[Ewald]

Code: Alles auswählen

Eingabevariable         Hein Mück aus Eckernförde     
Eingabevariable crypt   õ©¬[XZˆ`¿—„Ymya[%/Pà]

[AUGE_OHR]

hi,
[quote="Ewald"]

Code: Alles auswählen

Eingabevariable         Hein Mück aus Eckernförde     
Eingabevariable crypt   õ©¬[XZˆ`¿—„Ymya[%/Pà]

[Ewald]

hi Jimmy,
habe das grade mal getestet. Die Änderung auf .t. hat keine Auswirkung. Außer dass sich die Anzahl der möglichen Kombinationen erhöht hat
Gruß
Ewald

[Rolf Ramacher]

Hi Ewald,

ist die Länge denn gleich ? Probier es mal mit alltrim.

[AUGE_OHR]

hi,

muss ich noch nachschieben: Die Datenbanken laufen schon lange mit xbase++. Dort tritt das Problem mit crypt() nicht auf.

NTX oder CDX ? ANSI oder OEM ?
zeig uns doch mal deine DBESYS.PRG

Ich habe dann heute noch mal die Daten in den Datenbanken entschlüsselt

also wieder OEM "Umlaute"

und mit dem ADS und crypt() neu verschüsselt.
Dabei habe ich charset ansi eingestellt.

ich glaube da haben wir es. Muss man nicht die "Umlaute" in eine
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

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 ?

[Ewald]

Code: Alles auswählen

ein Schuss aus der Hüfte : 
Clipper = OEM 
ADS = ANSI

Hallo Jimmy,
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]

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.

[Ewald]

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

[Tom]

Hallo, Ewald.

War ja auch Quatsch. Du mußt bei beiden Schaltern GERMAN angeben, wenn Du mit OEM-Zeichensätzen arbeitest. Dann klappt's auch.

[Ewald]

Hallo Tom,
es geht leider nicht. Hast du crypt() und ADS im Einsatz ? Kann ich dir mal ein PDF zukommen lassen ?
Gruß
Ewald

[Tom]

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.

[Ewald]

Habe grade versucht, das mit ADS Bordmitteln zu lösen - sprich mit AX_Encrpyt und AX-Decrypt. Und ich fasse es nicht, das gleiche Problem. Ich kann wunderbar verschlüsseln, nur nicht wieder richtig entschlüsseln.

[Tom]

Hallo, Ewald.

Wenn Du mal testweise SET CHARSET TO ANSI setzt, wird es funktionieren. Aber das hilft Dir nicht. Siehe letzte Nachricht von mir. Eine kleinere Datei (Benutzerverwaltung) öffne ich per DBFNTX (auch bei Vorhandensein der ADS), um dieses Problem zu umgehen.

[Ewald]

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

[brandelh]

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 ....

[Ewald]

Ich werde mal antesten, ob ansi, foxcdx, ads und crypt() irgendwie problemlos unter einen Hut zu bringen sind... Wohldenn, mir fehlt der Glaube (mittlerweile)
Gruß
Ewald