Here is my code:

Imports System.Data.SqlClient

Public Class Form1

    Dim iConnect As SqlConnection
    Dim iCmd As SqlCommand
    Dim iRdr As SqlDataReader

    Private Sub dologin()
        iConnect = New SqlConnection("Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\UserData.mdf;Integrated Security=True;User Instance=True")
        Dim strLogin As String = "SELECT username, password FROM tableusername WHERE username = '" & userbox.Text & "' AND password = '" & passbox.Text & "'"
        iCmd = New SqlCommand(strLogin, iConnect)
        iRdr = iCmd.ExecuteReader
        If iRdr.Read = True Then
            Dim absen As String = "INSERT INTO tanggal(date) values(getdate())"
            iCmd = New SqlCommand(absen, iConnect)


            MsgBox("Gagal Maning")

        End If

    End Sub

    Private Sub absen_b_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles absen_b.Click
    End Sub
End Class

Is there anything wrong with it?

Recommended Answers

All 4 Replies

What happens when you execute the code ?

Are you getting any error ?

What happens when you execute the code ?

Are you getting any error ?

that the weird part, there is nothing happen. it likes the code seceded and the message "Berhasil!" is poped out..


There are a few things. For a start you are only closing the connection if iRdr is true. If the user name or password does not match the connection stays open. Thats wasteful.
Secondly, you're inserting the actual text entered into the user name and password text boxes into your SQL statement. That is REALLY bad as it leaves you open to SQL injection attacks. If I were to type 'steve or 1 = 1;' into the user name texbox, your sql statement becomes "SELECT username, password FROM tableusername WHERE username = steve or 1 = 1. The 1 = 1 is always true and so I log in without needing a user name or password. Thats bad enough but I can make things worse by using DELETE statements. If I manage to guess or discover a table name, say goodbye to your data. Use parametized queries to avoid that whole mess.
Hope that helps:)

Also consider not to use date as a field name as a best practise. That is a predefined keyword in any database.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.