467,894 Members | 1,540 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,894 developers. It's quick & easy.

Multiple frontends vs one complex frontend

Hello!
I have fully functional database that has back-end and one front-end.
The whole thing is setup to operate through the custom forms.
There are 4 different kinds of users who access the database. The forms and the data that are displayed vary depending on the user type. All that is done with a lot of global variables. Some of the variables store the type of user to determine what should happen in each event, making code rather complex and long seems like (or at least more complex then should be).
Even though itís working now I feel like there is room for improvement.

The question is whether I should consider making 4 different front-ends for each type of users (making code simpler, but duplicating some for different front-ends) or keeping the database the way it is now and improving what I can from there.
Oct 2 '07 #1
  • viewed: 1448
Share:
8 Replies
ADezii
Expert 8TB
Hello!
I have fully functional database that has back-end and one front-end.
The whole thing is setup to operate through the custom forms.
There are 4 different kinds of users who access the database. The forms and the data that are displayed vary depending on the user type. All that is done with a lot of global variables. Some of the variables store the type of user to determine what should happen in each event, making code rather complex and long seems like (or at least more complex then should be).
Even though itís working now I feel like there is room for improvement.

The question is whether I should consider making 4 different front-ends for each type of users (making code simpler, but duplicating some for different front-ends) or keeping the database the way it is now and improving what I can from there.
It seems as though you have set up a Pseudo Security System via the use of Global Variables which I really do not think is a good idea. Have you considered using Access's built-in Security System to implement your logic? With only 4 distinct Users, it should not be that difficult to attempt. The Globals would be completely eliminated, there would be a single Front End to distribute, Permissions would then be assigned via a User's Security Credentials. Let's see what the other Moderators/Experts have to say on the subject before taking my word on it.
Oct 2 '07 #2
It seems as though you have set up a Pseudo Security System via the use of Global Variables which I really do not think is a good idea. Have you considered using Access's built-in Security System to implement your logic? With only 4 distinct Users, it should not be that difficult to attempt. The Globals would be completely eliminated, there would be a single Front End to distribute, Permissions would then be assigned via a User's Security Credentials. Let's see what the other Moderators/Experts have to say on the subject before taking my word on it.
Thanks for the reply!

The problem is not even in security. The actual coding, that's what bothers me...
for example: i have a main form that consist of big listbox with (8-12 columns depending on the user), some texboxes and buttons. so when the user logs in i determine what type of user s/he is. And then i carry that user type in global variable through out the entire "session" while user is in database. that global variable will determine how many columns should be in the listbox and what rowsource should be. Same actions take place for just about any event on the forms. I have a lot of "if" and "select" statements ....

for example:
"user A" gets "form 1" with rowsource of "query1"
"user B" gets same "form 1" except the rowsource now is "query2".
if user A presses button1 one thing will happen
if user B presses that same button1 the other thing will happen....
except query1 or query2 are sql statements about 3/4 of a page long....
so with all the ifs' i have several pages of code just to setup one single listbox.

Same problem in just about every function/sub --> everything looks too complex and seems that it should not be...

however there are a lot of thing that are the same in the code. that's why have chosen one front-end design initially, but now i'm having second thoughts about it.
Oct 2 '07 #3
ADezii
Expert 8TB
Thanks for the reply!

The problem is not even in security. The actual coding, that's what bothers me...
for example: i have a main form that consist of big listbox with (8-12 columns depending on the user), some texboxes and buttons. so when the user logs in i determine what type of user s/he is. And then i carry that user type in global variable through out the entire "session" while user is in database. that global variable will determine how many columns should be in the listbox and what rowsource should be. Same actions take place for just about any event on the forms. I have a lot of "if" and "select" statements ....

for example:
"user A" gets "form 1" with rowsource of "query1"
"user B" gets same "form 1" except the rowsource now is "query2".
if user A presses button1 one thing will happen
if user B presses that same button1 the other thing will happen....
except query1 or query2 are sql statements about 3/4 of a page long....
so with all the ifs' i have several pages of code just to setup one single listbox.

Same problem in just about every function/sub --> everything looks too complex and seems that it should not be...

however there are a lot of thing that are the same in the code. that's why have chosen one front-end design initially, but now i'm having second thoughts about it.
How proficient are you in writing VBA code?
Oct 2 '07 #4
How proficient are you in writing VBA code?
I was able to accomplish all of my the projects one way or the other... may be not the most efficient way, but i'm always willing to do some research if i would have some thoughts of how to improve the code.
I've written decent amount of code with various complex calculations, recordsets, loops, ifs, etc.
What kind of suggestions do you have?
Oct 2 '07 #5
ADezii
Expert 8TB
I was able to accomplish all of my the projects one way or the other... may be not the most efficient way, but i'm always willing to do some research if i would have some thoughts of how to improve the code.
I've written decent amount of code with various complex calculations, recordsets, loops, ifs, etc.
What kind of suggestions do you have?
It seems like the 'Enable Security' approach is out give the current code context, and without actually seeing the Database, it is very difficult to recommend a specific approach. You stated that there is a lot of 'similar' code. Perhaps this 'similar' code can be placed in Sub or Function Routines that are declared Publicly so that they can be called from anywhere within your application. Again, I do not have the Database in front of me, so I cannot visualize if this approach is feasible. Some more details would probably be very helpful such as:
  • Size of the Database.
  • Purpose of the Database.
  • Explicit permissions for each User, what they can and cannot do.
  • Number of Database Objects broken down by Object Type (Tables, Forms, Reports, Macros, Modules, Querys, etc.)
  • Number of Global Variables utilized.
  • Number of Tables involved in Relationships.
  • Approximately, how many lines of code are we talking about (not only Standard Code Modules, but also Report and Form Modules.
  • Are there any Class Modules.
  • What is the entry point into the Database (Start Up Form, AutoExec Macro)?
  • I think you get the rough idea by now.
Oct 2 '07 #6
Jim Doherty
Expert 512MB
Hello!
I have fully functional database that has back-end and one front-end.
The whole thing is setup to operate through the custom forms.
There are 4 different kinds of users who access the database. The forms and the data that are displayed vary depending on the user type. All that is done with a lot of global variables. Some of the variables store the type of user to determine what should happen in each event, making code rather complex and long seems like (or at least more complex then should be).
Even though itís working now I feel like there is room for improvement.

The question is whether I should consider making 4 different front-ends for each type of users (making code simpler, but duplicating some for different front-ends) or keeping the database the way it is now and improving what I can from there.
I agree with ADezii if you are invoking a security based application then it makes sense to acknowledge the security model of Access which may serve to strip out most of any code you have that might be unnecessarily complex and which can be achieved by setting object permissions via defined groups.

You can then base your recordset code logic on IF CurrentUser() = "blah" THEN etc or permissions assigned via allocation to a group.' IsMember' etc

There are many useful areas of implementation of the security model designed to give a 'degree' and I say a 'degree' of protection at the very least without any extra overhead. I would even go so far as to say that it might also scale up better if you are able to reduce your codebase prompting you to keep to the ONE distributed frontend which in turn will ease your maintenance overhead.

My two cents worth

Jim
Oct 3 '07 #7
I guess it's almost impossible to give an advice like that without seeing a database.
Have about 60 pages of code and it keeps on growing....
With Access security i had problems before.
I have forms that are linked to the tables and from that form i need to have ability to change, delete, add items to the tables, run queries, etc. However i dont want the user to be able to see anything else besides that form. Of course i would hide all the objects and hide database window, but someone with little more knowledge would still be able to get in by holding the shift key....
And i was unable set up security limiting access to the table but still having ability to peform those functions through the forms...
but,,, the whole security is a whole different problem... perhaps i just dont know enough about it, but i've read a lot of online articles about it and seems there is no solution for me.
Either way I appreciate the responses!
Oct 3 '07 #8
keeping one front-end will ease the maintance, totally agree there!
Oct 3 '07 #9

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

116 posts views Thread by Mike MacSween | last post: by
32 posts views Thread by tshad | last post: by
9 posts views Thread by Graham | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.