We have a central Access database (with smaller peripheral databases attached) that we would like several users not in the same locality to work on through a network. We currently have the databases on OneDrive; we would also like to lock the database when it is being edited.
I see there is a relevant post that is 5 years old on StackOverflow:
Access database sharing strategies
We have the Office 365 version. Would the solution enable us to lock the databases when they are in use? Are there new solutions to help with our task? We are also willing to try other online storage options if they are better than OneDrive.
Thank you in advance.
The post you provide a link to is quote old now, and some of what it says it bang on still, but some of it is a little bit misleading.
Running an access file that is stored on onedrive sounds like a very bad idea to me.
The post mentioned "Windows Terminal Server". This is a good solution as in effect it allows multiple users to open their own copy of an access file that grabs data from a singel access database file stored on the machine they are accessing using WTS. You will need to investigate this more.
That said, I've never used the above.
I wanted to write as you should be aware that Access 2013 can be used with SQL Server to store it data. Some "slightly more expensive subscriptions designed for business" will give the subscribers access to Sharepoint and access 2013 can then be used to create "Access web apps", and Access makes it really easy to store the data on a SQL Server that is managed for you and really simple to use. Users can also enter and view data into what MS call "Access Views" which are essentiall basic access forms that can be used in a web browser.
My gut feeling is that the WTS route will be best for you.
It's worth noting that there can be considerable work to move data from an access file into SQL server using the MS tools. This depends on what features of access you use.
Related
I am tring to create an Access application.
I want the database (tables) to be online and the app (forms, reports) to be installed on each pc.
Is there any possible way to succeed this?
Will I need a dedicated server ?
Alternatively, is there any platform (free or not) that I can upload the whole Access app making it Web app?
I made a research and Sharepoint does not satisfy me at all.
Unfortunately, microsoft does not support Access web apps anymore.
Thanks in advance.
Your best and most low cost is SharePoint tables from an office 365 plan.
Remember, Access web publishing is NOT required if you migrate tables to SharePoint, and then place the front ends on each PC.
So even the most basic office 365 planes support SharePoint tables. (You don’t need Access web publishing for the SharePoint table feature). You one monthly plan of about $7 allows all 20 users to connect with the one account one $7 fee total for all 20 users.
You can’t use “files” like Access accDB ones over the internet with say OneDrive, or drop box etc. The reason for this is these web systems don’t support windows networking. So while you can pull a word file from such system, you cannot EDIT the file on that remote system. When you are done editing word, then you send the WHOLE file back up to the remote system and the word document is OVERWRITTEN.
Of course with Access, if each user were to OVERWRITE THE WHOLE file, then each user would thus always overwrite anything changed by any other user. So these systems do NOT support the ability to update ONLY BITS AND PARTS of the file. It is this “bits” and “parts” updating that allows two users to work at the same time and edit separate rows of data in the ONE file.
So Access is VERY different than the rest of office.
With word, or Excel, then you edit the document and then SAVE THE WHOLE document. That “saving” will thus overwrite the changes made by anyone else. So these “cloud” systems do NOT support the ability to only update “part” of the file – but only the WHOLE file.
Word, Excel etc. thus work on a “whole file” update model. However, Access requires the “special” ability of the windows file system that allows one to update ONLY PART of the file. And even more important is windows file system allows two people to update at the same time as long as they are updating “different” parts of the file.
What the above means is then you have to move the back end data file from a “file” based system to some kind of server database system. That means MySQL, SQL server, or SharePoint tables.
I made a research and Sharepoint does not satisfy me at all. Unfortunately, microsoft does not support Access web apps anymore.
I would not write off this choice. Access web publishing is NOT required for Access to use SharePoint tables. And that table option is VERY nice since such tables even work without the internet connection and will “sync” or “catch up” when you finally do get a decent internet connection. In other words this “sync” type of model is more like email then traditional links to a database.
This web based message system and technology is FAR BETTER than Access ODBC tables since “small” connection breaks that is common over the internet tends to make use of ODBC over the internet rather painful compared to SharePoint tables (they were built from the ground up with the internet in mind, while linked ODBC tables in Access were created 25 years ago, and they did not have the internet back then – so the design considerations of internet were not given to the ODBC choice.
I mean, you can make a car fly, but if you design the machine from the ground up as a plane as compared to a car, the result is a far better machine that flies. So there will be 100’s if not 1000’s of small choices made in the design of the product for its given intended use. So Access was around LONG before the internet – so most options don’t play nice over the internet. However the SharePoint table open is from the ground up based on internet connection technology – ones that often break, or even stop working.
I explain the table migration process to office 365 here:
https://youtu.be/3wdjYIby_b0?list=PL27E956A1537FE1C5
The other choice is to migrate the data to the Web hosting database system. Most web sites usually offer MySQL or SQL server as a database choice. However, ONE BIG detail is you have to find a web hosting provider that allows external ODBC connections. Today, less and less web hosting companies allow raw external connections to the database that drives the web site. (The reason of course is security).
So while say when you go to amazon to buy a book, the web site and web server system can pull information about books etc. from the database system. However, you on the outside cannot connect or link access to the database system that drives Amazon.
So while the web hosted server has full use of the database server, you as an external outside user (not from the web site) do not have such permissions.
So you need to find a provider that includes a database server, but in addition to allowing the web site to grab + pull data from database server, they also allow everyone on the planet who is connected to the wild and crazy internet to ALSO be able to connect to the database server (and by-pass the web site).
So as you can see, this is a big security risk because that database server now has to allow any crazy person on the internet to pull data from that database. I mean, I seen within say 5, or 10 minutes of opening up such database systems, you see 100’s if not 1000’s of logon attempts and people trying to link to your exposed tables! I mean, if all your users can link and see those tables, then so can the everyone else on the wild internet. So in a very short time automated bots will attempt to logon and link to those tables if they find someone crazy enough to “open” up their database system to allowing everyone to “link” or at least try to “link” to those tables.
So fewer and fewer web hosting companies allow external connections to the database that by-pass the web site. You need this by-pass the web site and go direct to database ability. The reason of course is Access is not connecting or linking to the web site, but needs to link DIRECTLY to the database system. (This thus has near nothing to do with the web site – you are to consume the database system, not the web system).
As noted, most simple is SharePoint and office 365. And this choice also has good performance WHEN the file sizes are limited and fit within the SharePoint table limits.
Another choice would be to purchase a monthly SQL Azure plan, and then again migrate your data from Access to SQL server. This setup will also work. They have a number of cool security features (you can restrict what IP address are allowed to connect for example).
Last but not least:
Your internet connection is about 10 times, or even 30 times slower than your normal office network. That means a typical wait time of say 3 seconds with your split application now on your office network will become a wait time of 30, or even 150 seconds if you connect over the internet (150 seconds = 2.5 minutes!!!!!).
This means you have to spend time optimizing the application for this setup. I explain this issue here:
http://www.kallal.ca//Wan/Wans.html
If you don't think this speed issue outlined in the above wans article does not apply to you then I suggest a re-reading it again and again until such time you realize this slower internet issue applies to you. Do the basic math - your internet connection will be 10 to 100 times slower then your cheap local office network. Do take more meds if you don't grasp this issue and don't think it applies to your case and use - it does.
One of the alternative options to Access Web App is PowerApps. It is one of the foremost suggestion to migrate Access Web Apps which is quite easy and powerful.
I would like to design a database application using Microsoft Access. Before I start there are some important features I want to make sure are available in Access.
In a multi-user environment can the database be accessed simultaneously by different users such that only individual records are locked/unlocked as necessary?
Does Access need to be "opened" or can a "front end" be designed so the user only sees menus, menu bars, tabs, data screens, etc?
Can the database design features be locked so the user cannot change any database features?
Thank you for your help.
AF
Yes, certain records can be locked.
For Example, if you work with an ADO Recordset:
recordset.Open Source, ActiveConnection, CursorType, LockType, Options
LockType defines the locking-mechanism used for the selected Query Source.
More Information on that: http://msdn.microsoft.com/en-us/library/ms675544%28v=vs.85%29.aspx
Usually you split your Database into an frontend and backend. The back-end only contains only the tables, the rest goes in to the frontend. The backend tables are then linked to the frontend. Here is a link explaining how to do that: http://www.fmsinc.com/MicrosoftAccess/DatabaseSplitter/
In the frontend file can be compiled, so that the frontend users cannot edit sources.
In response to the third of your initial questions please note that Microsoft Access offers the facility to convert an Access database to an executable file (having file extension "accde" where your forms, reports, code and macros are protected to a substantial extent. However the level of protection offered with regard to tables is low in that the same are directly accessible even in an accde. MS Access also offers the runtime version free of charge and does not restrict its deployment to as many users as you may require. It no longer offers user-level security. This feature has been replaced with an encrypted password feature. Thus you will have to insert your own design and code to impose access restrictions on different categories of users. Alternatively, to use the user level security feature, one has to develop his application in an earlier version of Access in which this feature was available and thereafter use a recent version to convert it. I am uncertain whether MS Access 2013 will entertain such a database but understand that MS 2010 will though it will not offer that feature when you create a new database inside it.
You can get SQL Express for free, it's a stripped down version of SQL Server. It will handle multiple user access significantly better and not come with the bloat/performance degredation issues that Access brings along.
There will be a slightly higher learning curve, but if you're looking to get your foot into the development world's door, you'll be much better off learning how to work with SQL Server than Access.
I have developed a few forms for analysing data on a access database. Now I would like to know if it would be possible to host the forms on a link over the net having the database in a different system. Basically I want the database to be in a different system, the user should see the forms and use it but all processing, must take place in the system where the database is. The user must then be able to see the results.
Is this possible?
No, it's not possible. The web has a separate client for user interaction (usually the browser) and a server for storage. Browsers do not support Access for GUI interaction.
However, you can still use Access for storage (although this is not advisable), but you will have to find a solution for converting the Access forms to web forms. Fortunately, there are plenty of tools available that can do that for you.
There are various limitations in Access/Sharepoint combination. Like union query is not supported in web access and other things. Access can be better deployed over net by using remote connection with mysql (or other server dedicated or cloud) as backend.
Since Access 2010, it is possible to run Access forms on-line. This can be seen in Access 2010: Outlook-Style Calendar in Browser, by Albert Kallal
I've created a database in access 2007 that needs to be used by 3 users. I'm stuck because I don't know whether to place a copy on each users' computer or to place it on their SQL server. Placing it on the server would mean one access point which is desirable for data consistency but I don't know whether I need ActiveX. Don't know how to use it either. If I place it one each computer how do I work around the master file updates? Can somebody please break it all down, I'm a NEWBIE!!
Your question seems rather confused to me. You mention a SQL Server, but you don't say your application uses SQL Server for its data storage.
Thus, I can only assume that you have a single MDB or ACCDB file with your data tables and forms and reports all in the one file.
The only proper way to distribute this app is:
split it into front end (forms/reports/etc.) with linked tables that point to the back end (data tables only).
place the back end on your file server and relink your tables to point to the new location of the back end.
give a copy of the front end to each of the 3 users, who will run it from their desktop computers. If you're concerned about distributing changes to the front end, something like Tony Toews's front-end updater is very useful.
Others have jumped in to say that you should put the data in SQL Server, but most 3-user Access apps don't need the power of SQL Server. If you're not given administrative permissions on your SQL Server, it could be quite difficult to continue to alter your application's database.
On the other hand, if your database is going to grow to 1GB or more, or if you have strict security requirements, or if the data in your database is so important as to need completely failproof backups, then SQL Server would be a reasonable data store.
For most homegrown apps, not so much.
The "best" way I've worked this out is using Linked Tables in Access to go to SQL Server (since you stated you have that..?).
Using access as a front end in this scenario isn't the best thing you can do, but with 2007, it's a bit better than if you were a few versions back. Check out this article for info on linking Access into SqlServer:
Import or link to SQL Server data
One easy way is to use the EQL Data plugin: http://eqldata.com
That way you can give a copy of the database to each user, but users can sync the database with other users whenever they want. You can also access your tables and queries on the web.
Two users wanted to share the same database, originally written in MS Access, without conflicting with one another over a single MDB file.
I moved the tables from a simple MS Access database to MySQL using its Migration Toolkit (which works well, by the way) and set up Access to link to those tables via ODBC.
So far, I've run into the following:
You can't insert/update/delete rows in a table without a primary key (no surprise there).
AutoNumber fields in MS Access must be the primary key or they'll just end up as integer columns in MySQL (natch, why wouldn't it be the PK?)
The tables were migrated to MySQL's InnoDB table type, but the Access relationships didn't become MySQL foreign key constraints.
Once the database is in use, can I expect any other issues? Particularly when both users are working in the same table?
I know this topic is not too fresh, but just some additional explanations:
If you want to use MS Access effectively, especially with bigger, multiuser databases, please do the following:
split your MDB into frontend application and backend (data only) files - you'll have two separate MDB files then.
migrate all the tables with data and structure into external database. It can be: MySQL (works very well, no database size limitations, requires some more skills as it's not MS technology, but it is a good choice in many cases - moreover you can scale your backend with more RAM and additional CPUs, so everything depends on your needs and hardware capabilities); Oracle (if you have enough money or some kind of corporate license) or Oracle 10g XE (if this is not a problem, that the database size is limited up to 4 GB and it will always use 1 GB of RAM and 1 CPU), MS SQL Server 2008 (it's a great pair to have MS Access frontend and MS SQL Server backend in all the cases, but you have to pay for license! - advantages are: close integration, both technologies are form the same vendor; MS SQL Server is very easy to maintain an effective at the same time) or Express edition (same story like with Oracle XE - almost the same limitations).
relink your MS Access frontend with backend database. If you selected MS SQL Server for the backend then it will be as easy as to use the wizard from MS Access. For MySQL - you have to use ODBC drivers (it's simple and works very good). For Oracle - please do not use the ODBC drivers from Microsoft. These from Oracle will do their work much better (you can compare the time needed to execute SQL query from MS Access to Oracle via Oracle ODBC and MS Oracle ODBC drivers). At this point you'll have solid database backend and fully functional MS Access frontend - MDB file.
compile your MDB frontend to MDE - it will give you a lot of speed. Moreover, it's the only reasonable form of distributing MS Access application to your end users.
for daily work - use MDE file with MS Access frontend. For futher MS Access frontend development use MDB file.
don't use badly written ActiveX components to enhance MS Access frontend capabilities. Better write them yourself or buy the proper ones.
don't believe into the myths that there are a lot of issues with MS Access - this is a great product which can help in may occassions. The problem is a lot of people assume it's a toy or that MS Access is generaly simple. Usually they generate a lot of errors and issues by themselves and their lack of knowledge and experience. To be successfull with MS Access it is important to understand this tool - this is the same rule, like with any other technology outhere.
I can tell you that I'm using quite advanced MS Access fronted to MySQL backend and I'm very satisfied (as a developer which is maintaining this application). My friends, the users are also satisfied as they feel very comfortable with the GUI (frontend), the speed (MySQL), they don't have any issues with records locking or database performance.
Moreover, it's important to read a lot about good practices and other people experiences. I would say that in many cases MS Access is a good solution. I know a lot of dedicated, custom made systems which started as an experiment in form of private MS Access database (MDB file) and then evolved to: splitted MS Access (MDE - frontend, MDB - backend) and finally to: MS Access frontend (MDE) and "serious" database backend (mainly MS SQL Server and MySQL). It's also important that you can always use your MS Access solution as a working prototype - you have ready to use backend in your database (MySQL - let's assume) and you can rewrite frontend to the technology of your choice (web solution? maybe desktop C# application - what you require!).
I hope I helped some of you considering the work with MS Access.
Regards,
Wawrzyn
http://dcserwis.pl
I had an application that worked likewise: an MS Access frontend to a MySQL backend. It was such a huge pain that I ended up writing a Win32 frontend instead. From the top of my head, I encountered the following problems:
Development of the ODBC link seems to have ceased long ago. There are various different versions floating around --- very confusing. The ODBC link doesn't support Unicode/UTF8, and I remember there were other issues with it as well (though some could be overcome by careful configuration).
You probably want to manually tweak your db schema to make it compatible with MS Access. I see you already found out about the needed surrogate keys (i.e., int primary keys) :-)
You should keep in mind that you may need to use pass-through queries to do more sophisticated SQL manipulations of the MySQL database.
Be careful with using lots of VBA, as that tends to corrupt your frontend file. Regularly compressing the database (using main menu, Tools | Database utilities | Compress and restore, or something like that --- I'm using the Dutch version) and making lots of backups is necessary.
Access tends to cause lots of network traffic. Like, really huge lots. I haven't been able to find a solution for that. Using a network monitor is recommended if you want to keep an eye on that!
Access insists on storing booleans as 0/-1. IMHO, 0/+1 makes more sense, and I believe it is the default way of doing things in MySQL as well. Not a huge problem, but if your checkboxes don't work, you should definitely check this.
One possible alternative would be to put the backend (with the data) on a shared drive. I remember this is well-documented, also in the help. You may want to have a look at some general advice on splitting into a frontend and a backend and code that automatically reconnects to the backend on startup; I can also send you some more sample code, or post it here.
Otherwise, you might also want to consider MS SQL. I don't have experience with that, but I presume it works together with MS Access much more nicely!
Gareth Simpson opined:
If it's only two users, then Access
should do just fine if you put the
.mdb on a shared drive.
Er, no. There is no multi-user Access application for which each user should not have a dedicated copy of the front end. That means each user should have an MDB on their workstation. Why? Because the objects in front ends do not share well (not nearly as well as Jet data tables, though there aren't any of those in this scenario using MySQL as the back end).
Gareth Simpson continued:
I believe the recommended max
concurrent users for Access is 5 but
on occasion I've pushed it past this
and never come unstuck.
No, this is completely incorrect. The theoretical limit for users of an MDB is 255. That's not realistic, of course, as once you reach about 20 users you have to program your Access app carefully to work well (though the things you need to do in an Access-to-Jet app are the same kinds of things you'd do to make any server database application efficient, e.g., retrieving the smallest usable data sets).
In this case, since each user should have an individual copy of the front-end MDB, the multi-user limits of Access/Jet are simply not relevant at all.
I know this doesn't answer your question directly, but it might be worth checking out the SQL Server 2005 migration tool for Access. I've never used the tool, but it might be worth using with SQL Server 2005 Express Edition to see if there are the same issues as you had with MySQL
Dont forget to put some type time/date stamp on each record. sometimes ms access will think "another user has changed or deleted the record" and will not allow you to make a change! I found this out the hard way.
In general, it depends :)
I haven't had a lot of problems when the application side has just been updating the data through the forms. You can get warnings/errors when the same row has been updated by more than one user; but Access seems to be constantly updating its live record sets all the time.
Problems can happen if Alice is already working with record 365, and the Bob updates it, and then Alice tries to update it with her changes. As I recall, Alice will get a cryptic error message. It would be easier for the users if you trap these errors and at least give them a friendlier error message.
I've had more problems when I was editing records in the VB code through RecordSets, especially when combined with editing the same data on forms. That's not necessarily a multi user problem; however, you have almost the same situation because you have one user with multiple connections to the same data.
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
Have you tried it first rather than just assume it will be a problem.
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
On the other hand I did once use Access as the front end to MySQL in a single user environment (me). It was a singularly unpleasant experience, I can't imagine it would become nicer with two users.