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")
        iConnect.Open()
        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
            iRdr.Close()
            iConnect.Close()
            Dim absen As String = "INSERT INTO tanggal(date) values(getdate())"
            iCmd = New SqlCommand(absen, iConnect)
            iConnect.Open()
            iCmd.ExecuteNonQuery()
            MsgBox("Berhasil!")

        Else

            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
        dologin()
    End Sub
End Class

Is there anything wrong with it?

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..

hm...

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.

This article has been dead for over six months. Start a new discussion instead.