Two problems happening and I just don't know why? :( (1 Viewer)

[brunces]

Friends,

Please, I really need some help, here because I don't understand what's happening.

I have a form which is opened based on these parameters, after a user logs in:

**** Code *****

Private Sub Form_Open(Cancel As Integer)

On Error GoTo Err_Form_Open

Select Case IntCodePerm
Case 0
Me.Form.AllowAdditions = True
Me.Form.AllowDeletions = True
Me.Form.AllowEdits = True
Case 1
Me.Form.AllowAdditions = True
Me.Form.AllowDeletions = False
Me.Form.AllowEdits = True
Case 2
Me.Form.AllowAdditions = True
Me.Form.AllowDeletions = True
Me.Form.AllowEdits = False
Case 3
Me.Form.AllowAdditions = False
Me.Form.AllowDeletions = True
Me.Form.AllowEdits = True
Case 4
Me.Form.AllowAdditions = True
Me.Form.AllowDeletions = False
Me.Form.AllowEdits = False
Case 5
Me.Form.AllowAdditions = False
Me.Form.AllowDeletions = False
Me.Form.AllowEdits = True
Case 6
Me.Form.AllowAdditions = False
Me.Form.AllowDeletions = True
Me.Form.AllowEdits = False
Case Else
Me.Form.AllowAdditions = False
Me.Form.AllowDeletions = False
Me.Form.AllowEdits = False
End Select

Exit_Form_Open:
Exit Sub

Err_Form_Open:
MsgBox Err.Number & " - " & Err.Description
Resume Exit_Form_Open
End Sub

***** End Code *****

"IntCodePerm" is a public variable (integer) declared in a module which receives the "code of permission" of the user who logged in. (There's a table for users with their respective codes.)

These are the codes of permission a user can have.

Level Code - Permission Description
0 - Can add, edit and delete.
1 - Can add and edit.
2 - Can add and delete.
3 - Can edit and delete.
4 - Can add.
5 - Can edit.
6 - Can delete.
7 - Can't do anything, just consult (search).

This form is based on a table. There are no combos in it, just single fields. I created my own navigation buttons; so they are:

Buttons:

- ButRecFirst
- ButRecPrevious
- ButRecNext
- ButRecLast

- ButRecNew (Add)
- ButRecDelete (Delete)

The VB code for the "ButRecDelete" is this one:

***** Code *****

Private Sub ButRecDelete_Click()
On Error GoTo Err_ButRecDelete_Click

DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70

Exit_ButRecDelete_Click:
Exit Sub

Err_ButRecDelete_Click:
MsgBox Err.Description
Resume Exit_ButRecDelete_Click

End Sub

***** End Code *****

I didn't create this code, Access did it by itself, as default.

And here are the problems I have:

1) I realized that even if "AllowAdditions" is False, if I click to go to the last record and then I click on "ButRecNext" button, it shows me a "blank record" and allows me to "add a new record", using this "blank one". This CANNOT happen! When the last record is being shown, the "next record button" cannot be enabled, or then it cannot show a blank record in which I can add something (as a new record).

2) I also realized that in all cases when "AllowEdits" is False and "AllowDeletions" is True, the button "ButRecDelete" DOESN'T work. This CANNOT happen either! That doesn't make any sense. If "AllowDeletions" is True, the button "ButRecDelete" has to work, independing on "AllowEdits" condition.

Note: When "AllowAdditions" and/or "AllowsEdits" are both True, everything works fine! So, I guess there's nothing wrong with the code or the variable. (Is there?)

Sorry, I know I wrote many things here, but it was just to expose my problem in a better way.

Please, if someone knows how to solve these 2 problems and wants to help me, I really appreciate it.

Thank you all for your attention, guys.

Hugz.

Bruno

 

[The_Doc_Man]

Well, the first thing to realize is that it doesn't matter what you think can or can't happen. What counts is what you actually told Access to do. So it is obvious you must have not told it what you wanted it to do. OK, working from there, you have two options.

1. Drive yourself nuts trying to figure out what happened.

2. Do something about it now and figure it out later. (I vote for #2.)

If you have this public variable, the FIRST thing I would do, no matter how hard it would be to do this, is to REVERSE the sense of it. You have encoded it so that ZERO lets you do everything. But maybe - just maybe - it would work better if it was SEVEN that gave you the keys to the kingdom. I say that 'cause it is SO darned easy to fail to define your variable correctly and come up with ZERO.

The second thing I would do is add code to each action button to test your public variable before you execute any of the DoCmd actions. Don't leave anything to chance. Don't trust your button-state code if you are seeing behavior that you didn't think you should have been able to see at all.

The third thing I would do is text-search your form's class module that contains all these button events to see if anywhere in that class module you redefine (overload) the IntCodePerm variable so that you are running into a scoping problem. (See above comment about getting zeroes so easily - this is one of the easier ways to do so.)

You MIGHT want to do these in reverse order as I named them, since if you find an overload it might immediately alleviate all other problems. But you never know.

 

[WayneRyan]

bruno,

You can shorten your case statements by:

If IntCodePerm In (0,1,2,4) Then
   Me.FormAllowAdditions = True
Else
   Me.FormAllowAdditions = False
End If

If IntCodePerm In (0,2,3,6) Then
   Me.FormAllowDeletions = True
Else
   Me.FormAllowDeletions = False
End If

If IntCodePerm In (0,1,3,5) Then
   Me.FormAllowEdits = True
Else
   Me.FormAllowEdits = False
End If

For example, on the Delete button code:

If IntCodePerm Not In (0,2,3,6) Then
   MsgBox("Not allowed.")
   Exit Sub
End If

hth,
Wayne

 

[Rich]

I'd have to ask why you'd allow deletions to a record but not edits?
in any case just use sql to delete the record

 

[brunces]

Thank you, guys!

Hi, Buddies.

- About ZEROS... I agree with you, The_Doc_Man, and I've already changed it. Now it goes from 1 to 8.

- About the variable... I've text-searched the class module for a possible redefinition for the IntCodePerm variable and I'm sure there's no other command which redefines its value. So I guess this is not the point yet.

- About the buttons... I had a "Select Case" with codes to enable and disable buttons "ButRecNew" and "ButRecDelete", depending on the "IntCodePerm" value (as you told me to do). It worked very well. But then I came to know about these "AllowXxxx" stuffs and I thought it would be better to use them, for maybe it was the "correct" way to allow or not what I want for my forms. But it seems they've brought me more problems than solutions. Maybe it would be better to use just the "AllowEdits" and, for additions and deletions, I use codes to enable and disable those specific buttons.

I think the problem with additions and deletions can be solved with codes for the buttons. So, this is not the "big trouble".

The most important problem I have is the #1 I wrote about... There's a way to add a new record, even if "AllowEdits" is False (with the navigation buttons, as I mentioned).

Well... Gonna keep on thinking here.

Thank you very much for your attention, The_Doc_Man and Wayne.

-----

Rich, believe it, I really have reasons to allow deletions without allowing edits. In some particular cases it's really necessary, here.

SQL could be a kind of solution. Gonna think about it.

Thanks, buddy.

Hugz for all.

Bruno

 

[The_Doc_Man]

There's a way to add a new record, even if "AllowEdits" is False (with the navigation buttons, as I mentioned).

When the default controls don't do what you want, you have a couple of options. One of which is to remove (disable) the navigation buttons and replace them with something of your own that does different checks than Access does.

The other is to look into using a stricter set of permissions on your users. Workgroup security would help you here, but it looks like you didn't want to go that way. I'm not going to second-guess you on it, but it could have helped you prevent unwanted actions based on your users' group memberships.