 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Multiuser / Networking / April 2005How multiuser access running on network server works
Can someone tell me what I would need to do to have an access application run on a shared windows XP server? We will have approx. 12 users all having access to the server. The users will not be doing updates to the data except for one decsription field in table. Do the users need to have anything installed on their workstations? Thanks, Karen Your users will need Microsoft Access....retail or runtime. They'll also need permissions on the share and folder. There is no such thing as Windows XP server though, so, that part of your question is unclear. You might be using a PC with Windows XP to share files, but WinXP isn't a server operating system.  SignaturePaul Overway Logico Solutions http://www.logico-solutions.com > Can someone tell me what I would need to do to have an access application > run on a shared windows XP server? We will have approx. 12 users all [quoted text clipped - 4 lines] > Thanks, > Karen Thanks Paul. I am using a PC with Windows XP. I am new to setting up infrastructure, so please bear with me. In my application, I will need to set permissions differently for each user. For example, some users will need to be able to see all divisions in the data table and others only a few. I was thinking of creating a table containing a login id and the division code. All queries will have to include this table in the join so that only the divisions that the given user is allowed to see will be returned. Can I have multiple user id's in Access? Can I use the windows login id as the access id? Thanks, Karen If you need to restrict use of certain functionality within your application, you'll need to set up user level security. File permissions and Access permissions are different animals, so, users will need to log in twice. For FAQs on user level security, see... http://support.microsoft.com/default.aspx?scid=%2Fsupport%2Faccess%2Fcontent%2Fs ecfaq.asp It sounds like you'll need queries with Run with Owner Permissions, and those queries will need to filter records based on CurrentUser. SignaturePaul Overway Logico Solutions http://www.logico-solutions.com > Thanks Paul. > [quoted text clipped - 12 lines] > Thanks, > Karen Paul, Thanks for the tips. Since I have never used security in Access before, I am a little nervous about beginning the security setup. I have just begun my development and thought I should get the security issues designed before continuing since my queries will most likely need CurrentUser filters. What is the development process in an access application? Do you do the development of forms and reports first and then go back and split the database and modify queries once the security is built in? Or do you from the start, build the secutiry, do the splitting of the MDB and then develop the application? I am feeling lost and confused. Thanks for your help. Karen I think you're on the right track....it definitely helps to PLAN for security before beginning development because it will have an impact on the overall design of the app. I would get the tables laid out, split the database, secure the back-end database, and then begin developing the application in the front end (being mindful of having planned for where security will be needed and what impact it will have on certain functions) after configuring some basic security within that file, i.e., for the database. While developing your app in the front end, set security for the various objects you create as you go. In cases where your users will need to work with a subset of the data within a given table, you'll need to create RWOP queries....which they should not be able to modify. You might need some type of user table (secured for admins only) to allow users to view data they did not create and use that for joins...i.e., if you have multiple users entering data for a department and they need to see each other's data, but not see data for other departments. SignaturePaul Overway Logico Solutions http://www.logico-solutions.com > Paul, > Thanks for the tips. Since I have never used security in Access before, I [quoted text clipped - 12 lines] > > Karen OK, here is how you do it: 1. Use the database splitter to create a "back end" database. Assuming your mdb is xyz.mdb, the splitter will create xyz_be.mdb. It will contain all your data. It will also establish links to the tables in xyz.mdb. 2. Here you must be carefull. Locate xyz_be.mdb in a server folder that all users have access to. Use the Linked table manager to correct a bad habit Access has when linking. It links using Drive letters (E:\AccessApp\xyz_be.mdb). Since all users will not have their drives mapped the same, use the absolute addressing (\\myserver\AccessApp\xyz_be.mdb). Then when you distribute it, the links will work for everyone. You do this in Tools-->Database Utilities-->Linked Table Manager. Be sure to check "Always Promt for New Location". When the common dialog box pops up and asks for the location, type it the absolute address. HINT: copy what you just entered, because you have to reenter it for each table. 3. Put nothing but tables in xyz_be. All other objects should be in xyz.mdb. 4. Your security issues can be controled using Access' security features, but it is too complex to cover here. Get a good book on it. 5. Distribute only mde files, not mdb, especially if you have security involved. 6. Users must have the same version of Access in which the app was developed or a runtime version. The run time version comes with the developer tools and can be distributed at no charge. 7. NEVER - EVER - NEVER allow multiple users to use the same front end mdb at the same time over a network. This is demanding disaster! Alway and only run it from the desktop. > Can someone tell me what I would need to do to have an access application > run on a shared windows XP server? We will have approx. 12 users all [quoted text clipped - 4 lines] > Thanks, > Karen > 3. Put nothing but tables in xyz_be. All other objects should be in > xyz.mdb. Are relationships a property of the tables and therefore in the be? I plan to make edits to my fe and then distribute to other users when tested. I'm assuming relationships are in the be, and therefore I should only edit them when I have exclusive access to the database. Is that correct? Best, Christopher Relationships are a property of the database. But you are correct that they should only be modified in the BE when you have exclusive access...likewise any modifications to tables, fields, or indexes. SignaturePaul Overway Logico Solutions http://www.logico-solutions.com >> 3. Put nothing but tables in xyz_be. All other objects should be in >> xyz.mdb. [quoted text clipped - 7 lines] > Best, > Christopher Unlike VB code, you can edit relationships and table designs without having exclusive access to the database. However, that does not mean that you should do so! Firstly, you do still need exclusive access to the particular object that you are trying to change: if you are trying to change an import table or relationship that everyone is using, you will still need to get everyone to stop. Secondly, many changes to BE design will require FE re-linking (or at least compact) at some stage, so you will need to stop everyone using the database BE to do that. Thirdly, many changes to BE design will require FE changes, so you will need to stop everyone to give them the new file. (david) >> 3. Put nothing but tables in xyz_be. All other objects should be in >> xyz.mdb. [quoted text clipped - 7 lines] > Best, > Christopher |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.