Coding Error. Login Forms. Help? (1 Viewer)

Declan

Registered User.
Local time
Today, 09:13
Joined
Jan 17, 2016
Messages
38
[SOLVED] Coding Error. Login Forms. Help?

I've created a login form that with all the code, it should work perfectly. I've double checked the names of all items mentioned in the coding, and it should appear fine.

However, when I try to log in, it presents an error code:


Run-time error '424':

Object required

This is a copy of my code:
Code:
Private Sub Command1_Click()
Username.SetFocus
[B][U][COLOR="Blue"]If [Username] = Table.[tbl_User].[UserLogin] And [Password] = Table.[tbl_User].[Password] Then[/COLOR][/U][/B]
MsgBox "Successful Login", vbInformation, "Central Bedfordshire Libraries Training and Induction"
DoCmd.Close
DoCmd.OpenForm "Frm_Main"
Else
MsgBox "Invalid Username/Password combination, please try again."
Me.Username.SetFocus
End If
End Sub

The line that is in blue, bolded and underlined is the line of coding that Access is stating isn't working properly, however I see no issues with the code, and after googling various solutions, attempting them, nothing seems to solve it. As a result, I rely on this forum yet again.

I'm using microsoft access 2013 Profesional Plus.
 
Last edited:

MarkK

bit cruncher
Local time
Today, 01:13
Joined
Mar 17, 2004
Messages
8,181
with all the code, it should work perfectly.
Lol. And then there's reality. ;)

What type of object is 'Table'? I don't see where it is declared or assigned a value or instantiated or anything.
 

Declan

Registered User.
Local time
Today, 09:13
Joined
Jan 17, 2016
Messages
38
The 'Table' is a table, then the 'tbl_User' is the name of the table, 'UserLogin' is the username column that has all the employee's usernames within it. Likewise with 'Password', only it storing passwords.
 

Declan

Registered User.
Local time
Today, 09:13
Joined
Jan 17, 2016
Messages
38
You can't refer to table data that way. DLookup() is one alternative:

http://www.mvps.org/access/general/gen0018.htm

Oh, one more question after viewing the thread you posted.

It says for normal usage, which is what I'm assuming I'd need here:

For numerical values:
DLookup("FieldName" , "TableName" , "Criteria = n")

For strings: (note the apostrophe before and after the value)
DLookup("FieldName" , "TableName" , "Criteria= 'string'")

For dates:
DLookup("FieldName" , "TableName" , "Criteria= #date#")

Does this allow for multiple possible answers? As my usernames and passwords can be made of numerical and alphabetical keys, and so is 'string' the one I'd need to use? Also, since it is ANY username within the field, will I just use this:

DLookup("FieldName" , "TableName" , "Criteria= 'string'")

One final question, sorry, since I obviously want the DLookup for the password as well, however it must look in the same record as the username was in, how would I form that? As, the string code above would allow a user to log in if they had user A's username, however entered user C's password, etc.
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 01:13
Joined
Aug 30, 2003
Messages
36,125
Very worrying if they thought it would actually work. Perhaps it was meant to be pseudo-code, and you were to come up with the actual code. Or maybe I'm giving them too much credit. :p
 

Declan

Registered User.
Local time
Today, 09:13
Joined
Jan 17, 2016
Messages
38
Unfortunately, I think you're giving him too much credit. Guess I might take questions to this forum and bypass him in the future... Aha.
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 01:13
Joined
Aug 30, 2003
Messages
36,125
Typically you'd only look up the password. Pseudo-code:

If DLookup("Password", "TableName", "UserName = '" & Me.UserTextbox & "'") = Me.PasswordTextbox

The criteria delimiters are based on the data type of the field in the criteria. In your case, the string type. And you'd want the form version.
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 01:13
Joined
Aug 30, 2003
Messages
36,125
Unfortunately, I think you're giving him too much credit. Guess I might take questions to this forum and bypass him in the future... Aha.

Being the contrary person I am, I'd call him on it. Or say "gee, I'm struggling, can you provide a sample db where that code works? Because based on what I've read, it can't possibly work."

But of course, I'm not hoping to get a good grade from the guy. :D
 

Declan

Registered User.
Local time
Today, 09:13
Joined
Jan 17, 2016
Messages
38
Ah okay. So is there not a way to look up both and confirm they are in the same record, then? I mean, I know access isn't a great software for security.. But I'd like the maximum security available on access, so.

Me.PasswordTextbox <- Being the textbox the user types in their password on the login form. So if mine was just called txt_password' you'd put Me.txt_password ? In that case, is Me.UserTextbox where the user enters their username?

Being the contrary person I am, I'd call him on it. Or say "gee, I'm struggling, can you provide a sample db where that code works? Because based on what I've read, it can't possibly work."

But of course, I'm not hoping to get a good grade from the guy.

I might do. He doesn't like me anyway because I proved that his database relationships wouldn't work due to him setting them up wrong, so it can't get much worse! :D
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 01:13
Joined
Aug 30, 2003
Messages
36,125
Well, the criteria ensures they're on the same record. The DLookup() basically says "look up the password where the user equals this user on the form". If you want to make sure the user exists, you can test first with a DCount() or test the password DLookup() for Null, which is what it will return if the user entered in the textbox doesn't exist.

And yes, you'd use your actual field and textbox names.
 

Declan

Registered User.
Local time
Today, 09:13
Joined
Jan 17, 2016
Messages
38
Okay! I think I've got it then, thanks for all the explaning and answering to all of my questions! You might have helped more than my actual teacher.
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 01:13
Joined
Aug 30, 2003
Messages
36,125
Happy to help! Sad that they get people to teach that don't actually know anything.
 

Users who are viewing this thread

Top Bottom