Split MS Access d-Base
Finally getting around to splitting our company's Access dBase that functions as our ERP system (customers, products, orders, etc.). The process seems pretty straightforward but I have a few questions.
It's my understanding that I will be able to create different front ends with this split database. I will need to create a front end for sales (2 computers), one front end for production operators (2 computers), one front end for engineers (6 computers), and a front end for me (everything). Some of the forms/queries will be needed at all stations, for example, (f-WorkHours). Other forms will be group specific (Sales: f-Customers, Engineering: f-PartSpecifications, or Production Operators: f-Throughput).
We have ~ 45 current forms, 30 reports, and 80 queries in our current database. What's the best way to manage this undertaking so that I support:
1) group changes (the ability to deliver timely and consistent f.e. changes to an entire group of users), and
2) revision flexibility (the ability to rev a single query or a form, say, f-customers) that might be used by one or all groups?
Thanks in advance.
ASKER
Ken,
If the users don't have Access installed on their computers, you will have to download the Access Runtime and install it on each computer. That gives them limited permissions to run the application but not make any changes to the application itself.
When I'm trying to manage users, one of the ways I like to do it is to use active directory to assign roles to people. Then, in the Access Application, you query Active Directory (see my article here) to determine what rights each user has and enable/disable buttons on your applications main menu based upon the logged in users Active Directory roles.
ASKER
While I always appreciate your answers and technical knowledge, I'm worried that time to learn/implement your solution will take too much time, Do you have any experience with Peterssoftware? I'll probably come out ahead if I can swipe the card and keep moving forward, but not if its going to create chaos in the future. I am now also curious to know if I could use Peterssoftware w/ Access Runtime - I'll ask Peter that one.
Thx
I am familiar with some of Peters work, but not his LASsie application, so I don't know how difficult it is to implement that security. But if you read my article and take a look at the sample database, you will see that it is pretty easy to implement.
Dale
LASsie is fairly straight forward to implement, but understand it's really not "security", but instead more of a navigation feature.
Here's one example: http://www.myaccesstips.com/deploy/deploy.html (see the Batch File for Startup section). You can make this as simple or as complicated as you want. I once created a small VB6 app that did the same basic thing, but needed to work with security (i.e. some users were not allowed to do certain things, and those had to be set on startup).
for security, your best bet is to deploy it as a .accde file, but then launch it using the runtime commandline switch.
But for functionality, you still need to disable features within the application based on user roles. You can either build that feature yourself, or you can use Active Directory.
Dale
What's the best way to manage this undertaking
You should establish a method for easy deployment of revised versions.
One method is to use a shortcut for the user to click. It is described in detail in my article:
Deploy and update a Microsoft Access application with one click
As pointed out 1 single application with user permissions to what they see and what not.
Just setup a login form with credentials stored as hashed values...use the hashed values to map forms/reports/controls/methods to users and that's about all.
With such a small userbase I wouldn't worry too much..probably you all drinking coffee together in the morning...😀
ASKER
ASKER