NULL erhalten, wenn Daten in Spalte

Question

sind Ich schreibe gerade eine sichere Anmeldung für eine VB.net-Anwendung, die ich erstelle. Die Anmeldeverifizierung wird über eine gespeicherte Prozedur auf dem SQL Server (2008 R2) ausgeführt. Ich brauche das Verfahren zur Überprüfung des Benutzernamens und des Passworts. Dann kick die Login-Nachricht (@responsesemessage) und die (@AccessLevel) zurück, damit ich feststellen kann, welches Formular als nächstes (Admin oder User) in meinem VB-Skript geöffnet wird.

Hier ist das Verfahren I

AS 
BEGIN 
    -- SET NOCOUNT ON added to prevent extra result sets from 
    -- interfering with SELECT statements. 
    SET NOCOUNT ON; 

DECLARE @UUID INT 
DECLARE @ResponseMessage NVARCHAR(250)  
DECLARE @AccessLevel VARCHAR(1) 
BEGIN 
IF (SELECT UUID from logins where Username=@pUsername AND PassHash=HASHBYTES('MD5', @pPassword)) 


     SET @UUID=(Select UUID FROM logins where Username=@pUsername AND PassHash=HASHBYTES('MD5', @pPassword))    
     SET @AccessLevel=(Select SecLevel FROM logins where Username=@pUsername AND PassHash=HASHBYTES('MD5', @pPassword))  

     SET @ResponseMessage=(SELECT statdesc from statuscodes where StatID='2') 


End 
    ELSE 
     Begin  
     SET @ResponseMessage=(SELECT statdesc from statuscodes where StatID='3') 
     Select @ResponseMessage as 'Result', @AccessLevel as 'AccessLevel' 

END Select @ResponseMessage als 'Ergebnis', @AccessLevel als 'Access' End

bisher habe Wenn ich einen Benutzernamen und ein Passwort eingeben, das ist In der Logins-Tabelle bekomme ich die korrekte Login-Nachricht, aber meine AccessLevel-Spalte kommt als NULL zurück. Die Variablen werden von einer VB.net-Winform, die ich gebaut habe, eingespeist.

Answer 1

Ihre IF-Anweisung ist in zweierlei Hinsicht falsch:

Zunächst sollten Sie IF unter Verwendung gibt und zweitens sind Sie nicht die 3 SET-Anweisungen in einem END BEGIN-Block gewickelt wird.

Dies führt dazu, dass das erste SET nicht ausgeführt wird, da IF nicht True ist, und die 2./3. SETs werden immer ausgeführt, weil sie nicht vom IF gesteuert werden.

Sie sollten Ihre SQL

IF EXISTS (SELECT UUID from logins where Username=@pUsername AND PassHash=HASHBYTES('MD5', @pPassword)) BEGIN 


     SELECT @UUID= UUID, @AccessLevel= SecLevel FROM logins where Username=@pUsername AND PassHash=HASHBYTES('MD5', @pPassword) 

     SET @ResponseMessage=(SELECT statdesc from statuscodes where StatID='2') 


End 

Sie können auch die ersten beiden Sätze in einer einzigen Auswahl kombinieren ändern, da sie den gleichen Datensatz in der Datenbank Targeting werden.

Answer 2

Versuchen Sie dies.

AS 
BEGIN 
    -- SET NOCOUNT ON added to prevent extra result sets from 
    -- interfering with SELECT statements. 
    SET NOCOUNT ON; 

    DECLARE @UUID INT 
    DECLARE @ResponseMessage NVARCHAR(250)  
    DECLARE @AccessLevel VARCHAR(1) 

    IF EXISTS(SELECT UUID from logins where Username=@pUsername AND PassHash=HASHBYTES('MD5', @pPassword)) 

    BEGIN 
     SET @UUID=(Select UUID FROM logins where Username=@pUsername AND PassHash=HASHBYTES('MD5', @pPassword))    
     SET @AccessLevel=(Select SecLevel FROM logins where Username=@pUsername AND PassHash=HASHBYTES('MD5', @pPassword))  

     SET @ResponseMessage=(SELECT statdesc from statuscodes where StatID='2') 
    END 
    ELSE 
    BEGIN 
      SET @ResponseMessage=(SELECT statdesc from statuscodes where StatID='3') 
    END 

    SELECT @ResponseMessage as 'Result', @AccessLevel as 'AccessLevel' 
END 

Answer 3

Vielen Dank für alle Antworten.

Während alle diese Blöcke von Code hilfreich waren. Ich habe die Ursache des Problems gefunden.

My gespeicherte Prozedur für die Anmeldungen herzustellen war die Einstellung der @pPassword als CHAR (20)

My gespeicherte Prozedur für die Überprüfung der Anmeldung wurde die @pPassword als VARCHAR Einstellung (40).

Also der Hash erstellt wurde die zusätzlichen Zeichen von der CHAR-Bezeichnung Factoring. Während der Verifizierungsprozedur wurden die zusätzlichen Zeichen abgeschnitten, bevor das Hashing überprüft wurde. Da die zusätzlichen Zeichen fehlten, waren die Hashwerte unterschiedlich und führten dazu, dass das Skript auf die Fehlernachricht gesetzt wurde.