0

My problem is I have a select query that gather all the data. And right now I want to display if it is ADMIN or EMPLOYEE. This is my stored procedure

ALTER PROCEDURE [dbo].[sp_selectusers]
    @username varchar(50),
    @password varchar(50),
    @result int output
AS 
BEGIN
    IF EXISTS (SELECT * FROM tbl_credentials 
               WHERE username LIKE @username AND password LIKE @password)
        SET @result = 1
    ELSE
        SET @result = 0

    RETURN @result
END

Database output

And this is my VB code

            cm = New SqlCommand("sp_selectusers", cn)
            With cm
                .CommandType = CommandType.StoredProcedure
                .Parameters.AddWithValue("@username", TextBox1.Text)
                .Parameters.AddWithValue("@password", TextBox2.Text)
                .Parameters.Add("@result", SqlDbType.Int).Direction = ParameterDirection.Output
                .ExecuteScalar()


                If CInt(.Parameters("@result").Value = 1) Then
                    MsgBox("Welcome " & .Parameters("@username").Value, MsgBoxStyle.Information)

               "If then 
                        Me.Hide()
                        Form_Admin.Show()
                    ElseIf
                        Me.Hide()
                        Form_Employee.Show()
                    End If" this code is incomplete

                Else
                    MsgBox("Account doesn't exists", MsgBoxStyle.Critical)
                End If

            End With

I want to add a condition ("MISSING CODE") here that if the query is ADMIN proceed to admin form else EMPLOYEE form but I don't know how to call the data in stored procedure.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Gerry
  • 73
  • 6
  • 1
    `CInt(.Parameters("@result").Value = 1)` should be `CInt(.Parameters("@result").Value) = 1`. Does it work as expected if you make that change? If not, what EXACTLY does happen? – jmcilhinney Feb 22 '23 at 03:05
  • As per the question guide, please do not post images of code, data, error messages, etc. - copy or type the text into the question. Please reserve the use of images for diagrams or demonstrating rendering bugs, things that are impossible to describe accurately via text. – Dale K Feb 22 '23 at 03:08
  • 5
    Aside... [AddWithValue is Evil](https://www.dbdelta.com/addwithvalue-is-evil/). Have a read of that article and always define SqlParameters with their correct data types and length/scale/precision. – AlwaysLearning Feb 22 '23 at 03:17
  • 5
    Aside... you are storing plaintext passwords in your database? Please don't. If you must use password authentication then please, at a bare minimum, use salted-and-hashed passwords. – AlwaysLearning Feb 22 '23 at 03:18
  • I don't actually know what you are asking. – Dale K Feb 22 '23 at 04:12
  • 1
    Side note: you should **not** use the `sp_` prefix for your stored procedures. Microsoft has [reserved that prefix for its own use (see *Naming Stored Procedures*)](http://msdn.microsoft.com/en-us/library/ms190669%28v=sql.105%29.aspx), and you do run the risk of a name clash sometime in the future. [It's also bad for your stored procedure performance](http://www.sqlperformance.com/2012/10/t-sql-queries/sp_prefix). It's best to just simply avoid `sp_` and use something else as a prefix - or no prefix at all! – marc_s Feb 22 '23 at 04:56
  • You should use = when looking for an exact match. `LIKE` is used when you want to something close to the value. – Sean Lange Feb 22 '23 at 14:18

1 Answers1

1

Just add @role output variable

ALTER PROCEDURE [dbo].[sp_selectusers]
-- Add the parameters for the stored procedure here
@username varchar(50),
@password varchar(50),
@result int output,
@role varchar( 30 ) output,
AS BEGIN

set @role = NULL
set @role = ( select TOP 1 Role FROM tbl_credentials WHERE username = @username and password = @password order by id )
set @result = ( case when not @role is null then 1 else 0 end )

return @result
END

In .NET code add a corresponding parameter as well.

You should also follow @AlwaysLearning suggestions in comments, namely:

DO NOT store plain text passwords. You have to either hash them (How to hash a password) or encrypt them if you really must have an ability to decrypt the password.

And fix AddWithValue code.

Alex
  • 4,885
  • 3
  • 19
  • 39
  • is this applicable if I have multiple admin or employees? – Gerry Feb 22 '23 at 03:41
  • I do not understand your question. All this SP does is return a role for a user with given username + password combo. – Alex Feb 22 '23 at 03:46
  • `@result` shouldn't be an output parameter because its already being returned as the `result`. Your SP only handles a single user at a time, so you only need a single output, unless you want to return multiple roles. – Dale K Feb 22 '23 at 03:46
  • To be fair I don't think this is what OP is looking for - I think the SP already does what it needs to, the code just needs to switch on the return value. – Dale K Feb 22 '23 at 03:48
  • Thanks I already get it now. but right now can I also return the column is_active in SP? – Gerry Feb 22 '23 at 03:55
  • Why? You should not allow a user to login if they are not active. Just add a `where` clause to your query – Alex Feb 22 '23 at 04:04
  • Okay done in the query. in vb code, is this correct? `.Parameters.AddWithValue("@role", SqlDbType.Text).Direction = ParameterDirection.Output` – Gerry Feb 22 '23 at 05:06
  • 1
    No. `AddWithValue` is wrong. See how `@result` is done. `SqlDbType.Text` is wrong, should be `SqlDbType.Varchar` (see https://learn.microsoft.com/en-us/dotnet/api/system.data.sqldbtype?view=net-7.0) because your string is under 8000 characters long – Alex Feb 22 '23 at 05:26
  • oh i see thanks a lot sir. `.Parameters.Add("@role", SqlDbType.VarChar, 10).Direction = ParameterDirection.Output` probled solved.! – Gerry Feb 22 '23 at 05:31
  • 1
    You have to pay more attention to little details: `"@role", SqlDbType.VarChar, 10` is not quite right (based on the code in my answer). What size is `@role` variable in the stored procedure? Your .net code should use the same size as what is returned by the stored procedure. And stored procedure variables should match data types and sizes of table columns! If you get it slightly wrong you can get "random" errors which are hard to find. – Alex Feb 22 '23 at 05:47