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.
Related
I have an MS Access 2016 application that a few people use in one department. I know this whole thing has web dev written all over it but this access database has been their process for a while and there is no time right now to switch over.
Recently, a different department wants to use this application, but having their own copy. Currently, if I need to make changes, I'll make the changes in a copy of the app, they send me a current version when I'm ready to import their data, I import it and send them back a new one. However, currently I copy the data table by table and past it into the new database. This is inefficient and tedious, and now with 2 sets of data I'd be doing this for, that's crazy. There's over 20 tables so I don't want to have to manually copy over 40+ tables across the 2 apps for even the smallest change like altering a message to the user.
I know I can copy the code so I can avoid importing the data, but sometimes for big changes I'll change over 15-20 vba files.
So, a couple questions:
1.Is there a way to generate insert statements for the entire database that I could run in a script? So when I create the new copy I just upload 1 file and it populates all the data?
2.Are there any kind of dev tools that will help this process? Right now I'm thinking that it's just a downfall of creating an MS Access app, but there must be some way that people have made the "new release" process easier. My current system seems flawed and I'm looking to have a more stable process.
EDIT:
Currently I have all my data stored locally, attached to the same access file as the front end. Since I will have 2 different departments using the same functionality, how do I manage the data/the front-end? These 2 departments should have their own access file to enter data using the forms, so having 1 front end between the 2 departments won't work.
Also, should I create 2 separate back-ends? Currently I would have nothing to distinguish what is being inserted/changed/deleted from one department from the other. If I were to attach a field specifying who entered the record, that would require a complete overall of all my queries which I don't have the time for as there are deadlines I need to meet.
First thing is to split the database. There is a wizard for this.
Then you can maintain the frontend without touching the real data.
Next, consider using a script to distribute revised versions of the frontend. I once wrote an article on one proven method to handle this:
Deploy and update a Microsoft Access application in a Citrix environment
I am attempting to move all my vb scripts that refresh my Access Tables and Queries to our new server which I log into remotely. I have done without problem with most of my scripts however there are a few that will now work and the thing they all have in common is they have linked tables from other Access databases in them. I run a script to refresh the that table and it works fine so it shouldn't be an user access problem. I haven't been able to find anything online about it, it's very strange. The linked table is in a database that is on a shared drive but again I refresh database tables from that shared drive all of the time without issue unless there's linked table involved. Help!
So right after I posted this I figured it out, hours of my time spent and it ended up being the most irritating thing. I had mapped the drives under the mapped letters in the databases instead of the actual address on the server.
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).
After searching around the forums I can find multiple issues with having several tables and one form, however I have the inverse problem. I have four separate forms that are all linked to the same table. No two forms edit the same variable on the table.
If people open up a single form, save it, close it, then move on to the next form the database works as intended. However, some people open up all the forms and forget to save/close the one beforehand. At this point, Access refuses to save the file stating that 'Another user has this file open' since the table is open in another form, even though no variable should overwrite each other.
Is there any workaround for this? I'd just like to have people be able to save their entered data from several forms to the same table. There will be no point in time that two people would access this table simultaneously, I just want to make sure we can save the data if someone opens multiple forms at once.
First, in a MS Access database multiple users can have same forms open. The only Read/Write issue would occur if users are working in the same record. Whoever enters the record first and begins updating would have the record-locked for him/her and users afterwards would get the warning message until the record is saved (or dirty event is removed). Users may be able to view but not be able to edit.
So your issue may be more an operational than a programming one. Try to organize users to manage specific records at a certain time or coordinate add/update work between team members. Of course this would be impossible if you run over a large company network with hundreds of users or online.
Still another solution would involve migrating all separate forms as subforms into one main form, so all corresponding records align at same time. But normally, subforms are reserved for join tables and not same table record sources. You can use tabs if space is an issue. This does not stop the record-locking issue but at least reduces the chances of it since less records are spread across separate objects. In fact this may prove to be better as users can move back and forth to other variables of the same record for reference on one form instead of opening/closing other forms or keeping the other ones opened.
Finally, it is highly advised if working in a multiple user environment and especially since you are connecting ODBC to systems like MySQL to split your database between FrontEnd (linked tables, forms, queries, macros, modules) and BackEnd (only tables). This setup prevents corruption, efficiently runs systems as only data is sent across the network and not whole application items, and overall fosters a better multi-user environment. Each user can have a copy of the FE on their local machines but all will connect to one BE on a shared network. To help, Access 2007-2013 has a button for this on the Ribbon under Database Tools.
I've used a dashboard that displayed buttons to open the forms needed and then used yourform.showdialog() to open up other forms in C#. This will make it so the user cannot use other forms until the form that is open is closed.
http://msdn.microsoft.com/en-us/library/39wcs2dh(v=vs.110).aspx
Good morning,
I'm doing a project, the customer prefers to use Access 2013 as the all in one package - front end, database etc.
In short the customer will give their users a blank copy of the database, which is taken on site and used to generate data based on calibration of equipment for that site.
The problem is the customer doesn't want anyone being able to copy the access database and use it themselves. So basically when on site he doesn't want the customer or anyone to go "oh that database is hand, give me a copy and I'll use it for myself".
I know I can compile the database but that will only protect the source.
Any suggestions on the best way to limit the use of the database?
It's been a few years and I may be foggy on parts of this, but I know you can get around password protected databases, and can bypass the 'startup' form/code so that you can open the database and view all the objects. You are correct that an MDE will not show the code. But if you have a table of valid serial numbers or MAC Id's, then I would have a module that encrypts the data in that table. Otherwise someone could add their values and still run the program? We also did some devious things like create an install package that would create some hidden file in some existing folder (with a calculated value as content), then if Access didn't find that file & content it would not run.