AX_Encrypt: Function is not declared(?) [Erledigt]

[ingo]

Hallo Leute,

vermutlich habe ich ein Brett vor dem Kopf - vielleicht gibt mir jemand den kleinen entscheidenden Tipp:

Ich möchte die Funktionen AX_Encrypt() / AX_Decrypt() nutzen um simple Strings zu verschlüsseln:

(...)
cret = AX_Encrypt( cString, cKey )
(...)

...das gibt die unten stehende Fehlermeldung - wohl von adsutil.dll fabriziert(?)

Was habe ich vergessen zu deklarieren?

Nebenfrage: ich könnte auch crypt() aus den ToolsIII benutzen.
Da ich aber nach Hinweisen aus dem Forum das Ergebnis nach Hex konvertieren möchte, bevor ich es in eine DBF zurückschreibe um Zeichensatzprobleme zu vermeiden, stelle ich mir die Frage woher die Tools wissen, ob ich den String ver- oder entschlüsseln möchte.

Code: Alles auswählen

Xbase++ version     : Xbase++ (R) Version 1.90.355
Operating system    : Windows XP 05.01 Build 02600 Service Pack 3
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: N VALUE: 67567616
          -> VALTYPE: N VALUE: 32
          -> VALTYPE: C VALUE: AdsEncryptBuffer
          -> VALTYPE: C VALUE: H1ax4y5P
          -> VALTYPE: C VALUE: 4856 7013 4017 6429 
          -> VALTYPE: N VALUE: 20
oError:canDefault   : Y
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Function is not declared
oError:filename     : 
oError:genCode      :         21
oError:operation    : dllPrepareCall
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :       2002
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Called from AX_ENCRYPT(301)
(...)

[Tom]

Hallo, Ingo.

Das sollte eigentlich in der ADSUTIL.LIB/DLL stecken, aber ich bekomme dieselbe Fehlermeldung, wenn ich das ausprobiere. Merkwürdig.

Crypt() macht vor- und rückwärts dasselbe. Crypt(cString,cKey) liefert einen verschlüsselten String zurück, wenn cString noch nicht verschlüsselt ist, und den ursprünglichen Wert, wenn cString den verschlüsselten enthielt. In Verbindung mit StrToHex() bzw. HexToStr() lässt sich das also auch nutzen. Ansonsten stecken in der XbpCrypt.DLL (Prof. Subscription) auch einige Hash-Funktionen, aber Hash-Verschlüsselungen sind nicht reversibel: Man kann aus dem verschlüsselten Wert nicht mehr das Original zurückgewinnen, sondern nur prüfen, ob z.B. ein eingegebenes Passwort verschlüsselt wieder diesen Wert ergäbe. In dieser Library stecken übrigens auch AesCrypt-Funktionen (!!) und ein aktueller 256-Byte-Hash (SHA256).

[ingo]

Hi Tom,

danke für die schnelle Antwort! Dann sieht ja ein bisschen so aus, als ob niemand AX_Encrypt() benutzt(?)
Ich probier's dann mal mit crypt() aus den Tools - die Professional Subscription werde ich mir vielleicht beim nächsten Zahlungstermin gönnen - wenn ich den Eindruck gewinne, dass der Zugriff auf Excel-Tabellen per ODBC deutlich schneller ist, als per ActiveX (CreateObject("Excel.Application") usw.)

Schönen Abend noch!

[Günter Beyes]

Hallo Ingo,

AX_Encrypt() will per DllCall die Funktion AdsEncryptBuffer (aus ace32.dll) aufrufen, aber die gibt es nicht, weil Extended Systems -- oder Sybase -- sie mittlerweile als obsolet eingestuft und in ObsAdsEncryptBuffer umbenannt hat.

Du kannst probieren, ob sie noch funktioniert, indem du im folgenden Code "Obs" vor den Funktionsnamen setzt, und gegebenenfalls AX_Encrypt() und AX_Decrypt() damit nachbauen.

Wenn nicht, helfen die Advantage-Newsgroups unter http://devzone.advantagedatabase.com/dz ... aspx?key=7 vielleicht weiter.

Ob das zukunftweised wäre, ist eine andere Frage...

AdsEncryptBuffer bzw. AdsDecryptBuffer waren seinerzeit per Dllcall so aufrufbar:

Code: Alles auswählen

DLLFUNCTION AdsEncryptBuffer( cPassword, @cBuffer, nBufferLen ) ;
  USING STDCALL FROM ace32.dll

DLLFUNCTION AdsDecryptBuffer( cPassword, @cBuffer, nBufferLen ) ;
  USING STDCALL FROM ace32.dll

Das Passwort konnte maximal 8 Zeichen lang sein.
Der Rückgabewert war 0 wenn erfolgreich, sonst ein ADS-Fehlercode.

Ebenfalls einen schönen Abend,
Günter

[ingo]

Hi Günter,

vielen Dank für den Hinweis. Dann werde ich mal checken, ob ich noch eine alte Dokumentation (Ver benutze - ich nutze die 9er ADS. Ein bisschen nervig ist das jedenfalls, dass Sybase da Dinge einfach so für obsolet erklärt. Ich hoffe, ich habe da nicht auf's falsche Pferd gesetzt.
Ich habe jetzt crypt() aus den Tools verwendet - das klappt und dann werde ich die Funktion auch nutzen. Alaska wird ja hoffentlich seine Abwärtskompatibilitätspolitik beibehalten...

[Tom]

Ein bisschen nervig ist das jedenfalls, dass Sybase da Dinge einfach so für obsolet erklärt.

Das wäre weniger nervig, würde sich Alaska häufiger um Updates der ADSDBE kümmern. Die letzte Fassung ist vom Mai 2006. Aber in der Roadmap ist ja angekündigt, dass sie in dieser Hinsicht etwas tun wollen. Nur sind "wollen" und "werden" in Alaska ja leider keine Synonyme.

[ingo]

Richtig, ich hatte ja die ADSDBE-Doku in der Hand, nichts von Sybase.
Und ich verstehe inzwischen auch die öfter geäußerte Unzufriedenheit mit der Verlässlichkeit von Alaska. Hatte doch Steffen Pirsig u.a. angekündigt, das "ADS-Handbuch" den (zu langsamen) Teilnehmern der Rösrather Entwicklerkonferenz irgendwie zur Verfügung zu stellen. Da kam ja auch nix mehr... Auf der anderen Seite - wo findet man schon den perfekten Service (den man versucht seinen eigenen Kunden zu bieten.)

[Tom]

Und ich verstehe inzwischen auch die öfter geäußerte Unzufriedenheit mit der Verlässlichkeit von Alaska.

Es ist ja keine generelle Unzuverlässigkeit. Der Support funktioniert meistens wirklich flink und ist, vor allem, kompetent. Und freundlich. Das gilt für ganz Alaska, wenn man es so sagen will.

Was noch nie funktioniert hat, das sind die Prognosen. Es ist meiner Erinnerung nach noch kein einziger avisierter Publikationstermin für irgendwas auch nur annähernd eingehalten worden. Die Planungen sind ambitioniert, die Roadmaps lesen sich großartig, aber die Jahre, in denen das dann auch verfügbar sein soll, kann man mit dem Faktor X multiplizieren, wobei X eine rationale Zahl größer 1 ist.