none
Stored Procedure - externe DLL RRS feed

  • Frage

  • Hi,

    habe folgende C#-DLL:

    using System;
    using System.Data.SqlTypes;
    using System.Security.Cryptography;
    
    public class Functions
    {
        [Microsoft.SqlServer.Server.SqlProcedure]
        public static SqlString Crypt(SqlString pClearText)
        {
            string clearText = pClearText.ToString();
            string tmpResult = "";
            HashAlgorithm hash = new SHA512Managed();
            byte[] plainTextBytes = System.Text.Encoding.UTF8.GetBytes(clearText);
            byte[] hashBytes = hash.ComputeHash(plainTextBytes);
            tmpResult = Convert.ToBase64String(hashBytes);
            return (SqlString)tmpResult;
        }
    }

    Versuche die ganze Zeit, die entsperchende SP zu definieren, die mir aber immer wieder mit der Meldung

    >Meldung 6551, Ebene 16, Status 2, Prozedur sp_crypt, Zeile 2
    Fehler bei CREATE FUNCTION für 'sp_crypt', weil die T-SQL- und CLR-Typen für den Rückgabewert nicht übereinstimmen.< oder ähnliches.

    Ich möchte eine SP haben, die mir den Wert des Ergebnisses so liefert, dass ich es in einer weiteren SP verwenden kann, z.B. zum lesen oder schreiben in einer Tabelle.

    gruß Hipp

    Dienstag, 5. Juni 2012 15:15

Antworten

  • Z.B.:

    CREATE FUNCTION [dbo].[Crypt](@pClearText [nvarchar](4000))
    RETURNS [nvarchar](4000) WITH EXECUTE AS CALLER
    AS 
    EXTERNAL NAME [SqlServerProject1].[UserDefinedFunctions].[Crypt]

    • Als Antwort markiert Hipp1010 Mittwoch, 6. Juni 2012 11:23
    Mittwoch, 6. Juni 2012 09:28
    Moderator

Alle Antworten

  • Es wäre praktisch, wenn du deine Vorgehensweise beim Ausführen für das CREATE FUNCTION etwas ausführlicher beschreiben würdest. Die Funktion ist so auf meinem Testsystem problemlos aus VS zu deployen.
    Dienstag, 5. Juni 2012 15:56
    Moderator
  • Eben das ist gerade die Krux bei mir. Wie muss die CREATE FUNCTION aussehen?

    Habs auf 2 verschiedene Arten probiert:

    1.) c# siehe oben

    und ->

    CREATE FUNCTION sp_crypt (@pCleartext nvarchar(4000))
    RETURNS TABLE (result nvarchar(4000))
    AS

    2.) C# ->

    public static voidCrypt(SqlString pClearText, out SqlString result)

    und entsprechende natürlich result = (SqlString)tmpResult) gesetzt.

    -> CREATE FUNCTION sp_crypt (@pClearText nvarchar(4000), @result nvarchar(4000)

    Wenn ich in C# das ganze als IN- und Output mit string mache und in der SP die Variablen mit varchar(255) definiere geht es auch nicht.

    Leider habe ich bisher keine Tabelle mit einer Gegenüberstellung beider Datendefinitionen gefunden (T-SQL-Datatypes <-> C#(VB)-Datatypes.

    Immer die Fehlermeldungungen bezüglich der incompatiblen Variablen-Definitionen. Ich finde bisher auch keine Beispiele mit solchen SP's, wo ich einen Parameter reingebe und z.B. einen Wert zurück bekomme. Diese FUNCTION müsste ich wieder in einer SP aufrufen, um dann mit dem Ergebnis zum Beispiel einen UPDATE auf die DB zu machen oder gegen einen Wert in der DB zu vergleichen.

    Gruß Hipp


    • Bearbeitet Hipp1010 Mittwoch, 6. Juni 2012 05:55
    Mittwoch, 6. Juni 2012 05:54
  • Z.B.:

    CREATE FUNCTION [dbo].[Crypt](@pClearText [nvarchar](4000))
    RETURNS [nvarchar](4000) WITH EXECUTE AS CALLER
    AS 
    EXTERNAL NAME [SqlServerProject1].[UserDefinedFunctions].[Crypt]

    • Als Antwort markiert Hipp1010 Mittwoch, 6. Juni 2012 11:23
    Mittwoch, 6. Juni 2012 09:28
    Moderator
  • hallo Hipp,

    gibt es einen Grund warum Du nicht die Funktion HASHBYTES vom SQL Server direkt benutzt ?

    siehe http://msdn.microsoft.com/en-us/library/ms174415.aspx


    Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

    Mittwoch, 6. Juni 2012 09:54
  • Hallo Daniel,

    im Grunde hast Du Recht. Wir habens jetzt zwar ganz anders gelöst, denn wir verschlüsseln das PW vorm versenden mit SHA512 und wollen dann eine SP auf dem Server aufrufen, die TRUE oder FALSE zurück gibt.

    Gruß Hipp

    Mittwoch, 6. Juni 2012 11:14
  • Vielen Dank. Das war schoin einmal ein kleiner Quanten-Sprung, denn die DLL, auch wenn wir sie in dieser Art nicht mehr brauchen liefert und das geswünschte Ergebnis zurück. Damit stehen uns grundsätzlich sämtliche Möglichkeiten offen, eiegen Logische Funktionen zu entwickeln, die wir hier in unserer Firma brauchen, wenn ich das richtig deute. Das ist richtig super.

    Gruß Hipp

    Mittwoch, 6. Juni 2012 11:23
  • Wenn es um Passwörter geht, dann sollte sowie so nur ein Hash gespeichert werden, d.h. du brauchst SQL Server seitig eigentlich keine Nachbearbeitung durch eine Hash-Funktion.
    Mittwoch, 6. Juni 2012 11:49
    Moderator