general question (1 Viewer)

[rainbows]

i have my database of which you all have kindly helped me with . it had about 30 tables , 40 forms , they will be 7 people using it
i have split the backend away and put a copy of the front end to each laptop . although there is a button for them to get at there own department and maybe on each form they have there is about 10 buttons or navigation forms on there from . my question is should i design computer so they can look at the all there own forms from there navigation bar

 

[Gasman]

Is there any need for them to use a dept other than their own?
Business need would define that surely?
You could default to their dept and then if they do need to go another dept, they just find that form and choose another dept?

 

[rainbows]

the issue is i really would prefer them not to be able to go to any other form/forms that dont relate to them thats why i closed the navigation pane off. each department is pass worded i just did not know if you had a form with a few navigation forms on the same form it slowed it down or anything

for example everything in sales is on this one form there is a total of 15 options they can look at

 

[Gasman]

So you restrict them.
Store their dept with their login details and only show what they need to see?

When I wrote a system for a bank, some users had higher authorisation limits, and that was stored with their userid.
They got allocated the higher amount for compensation cases.

Your situation is very similar?

 

[rainbows]

yes , i dont want them going to purchasing, stores, quality , finance forms , etc, but if each computer had say the same 40 forms on them is that slower than having there own say 12 forms on them ?

 

[MajP]

yes , i dont want them going to purchasing, stores, quality , finance forms , etc, but if each computer had say the same 40 forms on them is that slower than having there own say 12 forms on them

No. It will not be slower. You have to weigh your coding time vs configuration management time. Depends on what you are good at. Having one db that locks users to only their stuff may be harder to make then simply making different users a different front end tailored to them. Maintaining configuration management of multiple types of front ends and getting them to the correct people may be harder.

 

[The_Doc_Man]

yes , i dont want them going to purchasing, stores, quality , finance forms , etc, but if each computer had say the same 40 forms on them is that slower than having there own say 12 forms on them ?

Totally agree with MajP. Those 40 forms are all equally fast to select. The speed difference caused by different content of the different forms will hardly be noticeable unless one form has multiple sub-forms or multiple layers of sub-forms that other main forms don't have. Otherwise, every form should be equally fast.

MajP's comment about the issue of maintaining multiple FE files, each targeted for different groups, is also spot on. You do better with a single FE file that contains everything but just doesn't SHOW everything - based on something in the user's login record - is PROBABLY the better way to go from a long-term maintenance viewpoint. If you have trouble updating something in one file, how much harder will it be if you have to update it in six files?

 

[Pat Hartman]

I'm assuming that some of the tables are used by multiple departments. If not, then there is no reason for the functions to be combined. If you are POSITIVE there is no overlap with the functionality and one person will NEVER have to have access to more than one department's forms, then splitting is rational. Otherwise, I would keep everything together and use the menu to separate what each person can see based on their login.

Here is a sample switchboard that will help to separate what each person sees based on their login

Switchboard with simple security

This is a custom switchboard. It expands on the Switchboard Items table to add four additional columns to define view/edit/add/delete security levels for switchboard items and forms/reports referenced by them. It includes tables to manage users and also to assign them security levels. The user...

www.access-programmers.co.uk

 

[MajP]

Couple of things.
1. You may want to show and hide the ribbon and nav completely depending on access. See demo if you need that.
2. Personally I hate when a see a record selector in single form view. Yours has two and looks confusing.
3. I would open only one form at a time and make it pop up. IMO that tabbed form view is for development or personal use. I would open Sales Orders as Pop Up and most likely modal.

 

[bob fitz]

they will be 7 people using it
i have split the backend away and put a copy of the front end to each laptop

Is the network a wired network?

 

[Pat Hartman]

I agree, the users should NEVER have access to the Navigation pane. In addition to what @MajP suggested, @isladogs has an extensive description of how to lock down an application on his website that you might want to review.

I also don't like the look of single view forms with record selectors, however, if your application is such that multiple users might end up trying to edit the same record at the same time, then I would let the record selector show so I can see if some other user has locked the record I want to update. For most applications, this isn't usually a problem so I almost always also hide the record selectors for single record forms to give the form a cleaner look.

And finally, I abhor the tabbed view for forms and always switch to overlapping windows. Usually I start new apps by copying my template where I have all my most used common code as well as a switchboard and my lookup tables manager. I rarely allow two forms to be visible at one time and if I do, the second is opened as a dialog so the original form cannot regain the focus until the popup closes. Makes for fewer mistakes by the user and a cleaner process. I've attached a sample database that shows how I "chain" forms so that spawned forms can be opened by multiple different calling forms and when they close, they reopen the form that opened them.

Chaining Forms

Many people open multiple forms at one time. This is especially prevalent when you are using the tab view which is the default. I find that to be confusing for users so I developed a simple technique that uses the OpenArgs to allow one form to open another in DIALOG mode and then hide itself...

www.access-programmers.co.uk