Lawks a lordy your naming conventions are horrendous..
Doing stuff like this is just asking for trouble:
If CBool(CInt(dlg.txt_login_userName.Text.Length) And CInt(dlg.txt_login_password.Text.Length <> 0)) Then
I'm struggling to work out what this logic actually is. You convert to an int, something that is already an int, and then logical And it with the result of (converting a (process that compares two ints resulting in a Boolean) to an Int)
What does this mean?
Don't make huge blocks of code (don't write IF[test vailidity of user input] and then 30 lines of code underneath it.) - it's much cleaner to do all your validation at the start of the method, if(test for bad)then return, rather than if(test for good)then hundreds_of_lines_of_code.
The following is far more readable and understandable:
Protected Function Allowed() as Boolean
Dim dlg As New frm_login
If dlg.ShowDialog = DialogResult.Cancel Then Return False
'no comment on the wisdom of making the text boxes public instead of making a property
Dim strUserN As String = dlg.txt_login_userName.Text
Dim strPassW As String = dlg.txt_login_password.Text
'this check should be done in frm_login, not here. It should NOT be possible to
'exit the form using OK button if one of the values is length 0
If strUserN.Length = 0 OrElse strPassW.Length = 0 Then
MessageBox.Show("Please enter a username and password", "User Verification Needed", MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
Return False 'stop returning the function name! It's totally confusing!
End If
Now, to the actual problem, I'm really struggling to reproduce your issue. I put both the dataset entities on the form, made a button to fill them and clicked it repeatedly. None of the values filled from the DB increase upon fill.
Both buttons on your login form were set to be dialogresult.Cancel, though you reassigned them in code. Don't do this, because as soon as one of them is clicked, it will close the dialog. That effectively prevents you from doing any error checking and keeping the user on the login form until they sort out their error
Actually, I decided to rewrite portions of your app, with standard .NET naming conventions and practices. You'll notice:
* It's a lot less wordy. Fewer words = more tidy code
* Fewer comments. I write cleaner code that speaks for itself rather than being overcommented
* Fewer nests. Reduces mess, easier to work out where you are and what is happening
* Error checking at the start of a method, and returning if something doesnt pass
* Returning actual sensible values instead of returning method names
* Case conventions sorted out
* Stopped making everying Friend access; that just promotes poor coding style by directly reaching into classes and taking/changing values
* Added properties for things like the login form u/p
* Private members have names starting with _
* Underscores removed from class names, Dataset renamed to UsersDS, but instance on mainform renamed to _usersDS -> vb has a horrible habit of calling form variables the same name as the type, which is just plain up retarded
I've attached the project as a learning point. During the rewrite, I noticed something that is probably the root cause of your "increment problem" and I'm afraid to say it's something daft that you did that I cant quite explain.
In your userList table you have a userLevel field, but this might not be the userLevel itself. It is the FK of the PK of the userLevel table that has levelID as the PK, and another field, again called userLevel. The problem is that all 3 fields I duscuss here are numeric. userList.userLevel 1 corresponds to levelID 1 corresponds to userLevel.userLevel 0
Noting of course that 1 is one greater than 0, I strongly suspect youre getting totally confused as to what youre downloading from where, because you've named everything the same.
Here's a tip to solve this one:
Stop using "magic numbers" in your app, and call your columns something that makes it obvious that they are an ID value that is looked up elsewhere.
Personally I would prefer to see:
UserList.UserLevelID -> LUTUserLevel.UserLevelID, LUTUserLevel.UserLevelNumber
My rule is:
"Any column whose name ends in ID is a column containing values looked up elsewhere"
"To determine the name of the relevant lookup table, remove the ID, and prepend LUT"
"In the LookUp Table (LUT), the PK column and FK column that are joined have the same name, i.e. UserList.
UserLevelID -> LUT
UserLevel.
UserLevelID"
Now, about magic numbers. Magic numbers are a pain in the arse. The concept of using 1 to mean admin, 2 to mean backup, 3 to mean guest.. It's just dumb, because when you start using several different columns full of magic numbers it takes too long to look them up to mean something. Part of the reason that Enum,s exist is because magic numbers destroy code's ability to document itself. If you'd used A, B, G (admin, backup, guest) for userLevelID, you wouldnt have ended up confusing it with 1,2,3 for user levels. Lastly, a flags based system is much better than a level based system. Users must have certain flags to perform certain ops. Flags in my apps are typically a letter that is as non-magic as possible. A for admin functions , P for printing etc
