I have 2 Access 2013 databases, A and B. A is used as a front-end with links to tables in B. A is used by multiple users. Sometimes when opening, the links need to be refeshed using "Linked Table Manager." Sometimes the "Linked Table Manager" will show the linked tables being in an upper level folder, which is not the case. Is there something I can do to have A always open without the need of refreshing/resetting the links? Could multiple users be an issue?
Thanks
Your problem is most likely that not all users access the two database files using the same network path. The only reason I can think of that the links would not persist is if the front end is opened in a way that the path to the back end does not exist or is inaccessible.
If you are using mapped drives make sure all relevant drive mappings for all users are the same, or even better create your links using absolute UNC paths.
Just make sure that the drive/folder on which the backend (base B) is stored is mapped the same way on all clients.
Or link the tables using UNC (\\myServer\someShare\folder\filename.mdb) instead of mapped drive (s:\somefolder\filename.mdb).
Related
I have an Access database, split into two. One is the front end with all objects, linked to the other database - containing the tables. Both are in the same folder. Locally, the drive is G:. In our other office in another city, the drive is also G:. However, when a colleague in the other office opens the front end database, he gets an error message that it cannot connect locate the G:\ drive for the linked tables. I think there's a difference in the drive name. I know I can add VBA upon the database opening to change the link to that of the current folder. However, if two people in different offices are using the database at the same time, I think that will cause problems as each user would need a different link. Any suggestions will help!
Thanks,
Jeff
You need to map the tables to the explicit folder path. Or the UNC address. It would start with \servername\folder...
I have done this several times, but, access will run very slowly across large distances and outside of a LAN. I would reccomend importing the table if it is used for reference, and create a copy within the front end. Of course, have the front end located on the users PC for fastest accessibility and response. If you are actively working with records in the table, use a query to add and edit records in the table instead of a bound form. Otherwise everything will slow down.
I split my DB and now when I try to change some information on a few queries, I can't access them. I have a front end and a back end and understand that I should make changes to queries/forms via the front end, but they are grayed out and inaccessible.
At this point, I tried unsplitting the DB (which I believe I did), but I still can't edit those queries or forms.
I can click on the query/form and see the result of it, but I can't get to design view to edit it.
I'm taking a shot in the dark and saying that in the process of splitting your database, you either created your front-end in an accdr or accde format (a runtime application). The purpose of this is that you shouldn't be able to open queries or forms or tables in design view on the front end. You can just open your database and save it again as an accdb file and continue as normal.
If you're having other problems with the linked tables, I suggest you open the Linked Table Manager and refresh the links (if you moved the backend file, this is necessary).
I would recommend trying to proceed as normal by using Shift Bypass just to be sure. ( Hold the shift key when you start the database. Then attempt to modify in design view).
If these fail, I would attempt to copy the queries and /or forms if possible and create new ones.
Background:
I am making a website where I want modular administrative rights for read/write/edit priviledges. My intent is to allow for any number of access level types, and to base it off of folder structure.
As an example, root admins would have read/write/edit for all site pages. Group A may have read/write/edit to all files in the path www.example.com/section1/ (including subfolders), Group B would have read/write/edit to all files in www.example.com/section2/, and so on.
I have considered two options to impliment this: create a MySQL database that would hold:
Group Name (reference name for the access group)
Read (list of folders the group can read separated by comma)
Write (list of folders the group can write new content to separated by comma)
Edit (list of folders the group can change already existing information separated by comma)
The other option I considered is creating a 'GroupAccess.txt' file somewhere and hand-jamming the information into that to reference.
Question: What are the advanatages of each of these systems? Specifically, what do I gain from putting admin access information in a database versus a text file, and vice versa? (i'm looking for information on potential speed issues, ease of maintainability, ease of editing/changing the information that will be stored)
Note: I'm not looking for a 'which is better', I want to know specific advantages so I can make a better informed decision on what's best for me.
The first thing that comes to mind is that the database would be more secure over a text file for the simple reason a text file can be read over the internet as most web servers serve .txt file by default, this would allow for users with restricted access and non-users of the site to see the whole structure of you site and in turn can make you more open to possible attacks on certain areas of your site.
Another benefit of using a database is that you can easily use a join to check is a user has access to some content in the database where as with a file you'll need to read the file get the permissions and the go build the SQL and get the data from the database.
Those are just two of the things that have stuck out from reading your question, hope it helps.
In Access 2007, I split my database (which only contains tables and forms) into front end and back end. I want my front end to only have forms, while my back end only have tables.
When I split the database, the front end has tables and forms while my back end only has tables. When I try to remove the front end tables, the front end forms don't work.
I am completely new to Access and cannot find the answer.
In the end I want to give the forms out to multiple people and not have them see what other people input into the forms and to have the information on the table in the backend.
Thanks in advance!
You should probably have a look at using linked tables in the front end
About importing and linking data and database objects
MS Access: Link to a table in another database in Access 2007
A linked table in Microsoft Access is not actually a table that contains any data. It is just a shortcut to a table that resides in a different database, usually called the backend.
When you split your database the front-end should contain forms, queries, macros and code modules. And also linked tables that point to the backend database.
The backend database therefore would just contain the base tables.
Note if the backend database is moved then the linked tables will no longer work as the link would be broken.
You can either manually split your database or use the menu option built into the user interface, In Access 2007 click on database tools, then in the move data group click on access database.
To manually link tables, open your front end database and select External Data on the ribbon then click Access then after you've selected the file name make sure you select the 2nd option to link the table in the dialog box that opens.
It's a good idea to put the backend database on a server that does not get turned off and when linking avoid using mapped drives in case all users have not got the same letter mapped to the same folder share.
I'm looking to make a hopefully rather simple document storage system in sql 2008. We have a general idea of the elements we need, some meta data storage, filesteam, etc, but there are a few things we aren't quite sure of.
Specifically, we would like to implement a fake folder structure, as well as some (flexible) permissions. Permissions could be on a group level or by individual users, and should we should be able to specify no access, read, read/write, on either file level or folder level.
I'm not looking for someone to write this schema for me. But what I am hoping for is someone has resources that would cover these topics?
Thanks
~Prescott
I think you should go with the classic route of having a documents table that would hold the docs (If using 2008 or above look at FILESTREAM). The meta tables would then link to that.
Your folder structure could be achieved by having a folder table, the material table could then have a field to show which folder the material is in.
To get the sub folder levels you would just have a parent folder field in your folders table self linking back to the same table. You can then render that up in a treeview control in what ever flavour language you wanted
Have you looked at FILESTREAM Storage in SQL Server 2008?