Form States and User Access (1 Viewer)

[DevastatioN]

Just curious how many others go about building databases this way, and if they notice any slowdowns due to excessive code.

In regards to form states (form in edit mode, add mode etc.). I run code in the OnCurrent event that checks if the current record is a new record, if it is then "Save" and "Cancel" buttons become visible and the "Close" button becomes invisible. This allows a user to specify when they no longer want the record to be added, or when it's approved to be saved (this is also where I check for required fields etc.).

If there is a current record, then Save/Cancel go away and only a "Close" button is visible which simply closes the form. I control users greatly as access knowledge in my office is very limited, so I make full use buttons and coding, so no X in the top right corner of forms etc.

In regards to user access, we have strict policies for who can access what in our systems. I create a user table and a bunch of Yes/No fields for visible options. Whenever a form is opened, code runs that checks the current user, opens a recordset of their rights, and depending on values will hide and unhide or lock and unlock certain fields and options.

I would imagine this is pretty common practice depending on security restrictions in databases, or are there other ways most go about this? For example, I guess I could create a whole new form for new records, and viewing records, but then any update to one form visually has to be applied exactly to the other forms.

For those who do something similar, do you ever notice any slowdowns based on this amount of code being run? I do find slowdowns can occur when there are 5 or more users in the system, but I believe it's mostly due to our poor network drive performance, as even systems without excessive code can take just as long.

Just curious what other people do to control form states and restricted user access.

 

[MarkK]

No, the code to provide the services you describe doesn't sound excessive in any way. I would expect data access, either network issues or inefficient queries or search/sort on non-indexed fields, to generally be a more likely culprit if an operation takes too long to complete.
An aside: One user interface preference I have is to not hide buttons that aren't currently available, but rather disable them. Hiding things can make your form design look wobbly, and leaving unavailable choices visible can still serve to train users about what the full set of options are. Some users might only do specific jobs in your system, so maybe they only ever open a form in Add mode. That user might never see one of your hidden buttons and never learn to fully use features you've provided.
I think this is what Microsoft calls "Discoverability."
I commonly use wizards to add more complicated items, items that require one or more child items, or items that require more complex validation, and then deny the user the use of "Add" mode altogether.
Cheers,