I am looking into building an access database that will replace a very frightening combination of excel spreadsheets that are linked together. The files for the current spreadsheet system are located on our Windows Storage Server, which has a mapped drive to the directory they use. Multiple users access this system as it host inventory, ingredients used in each product and pricing for everything. I believe using a database is a MUCH better Idea. As I am visioning it, If i split the database it would give me a front and back end. allowing multiple users to access and make changes at the same time, With out Corruption! woo-hoo!!!
Is this correct? and has anyone implemented this? did the end user find using the database easy enough? any problems with this that i did not for-see. I have read that it is also possible to have the front end locally on the users computers. True/good?
Feel free to share any experiences!
Access works very well for small offices, if it is set up properly. The database must be split, with each user having a copy of the front-end. This does not mean that each user needs a full copy of Access, the runtime version is sufficient. 2007 runtime is free (http://www.microsoft.com/downloads/details.aspx?familyid=d9ae78d9-9dc6-4b38-9fa6-2c745a175aed&displaylang=en)
You should read this thread that deals with many misconceptions: Is MS Access (JET) suitable for multiuser access?
This should go over to StackOverflow.com, and I've voted to move it over.
That said, Access and Multiple Users = disaster waiting to happen as the number of multiple users goes up. You should seriously consider switching over to SQL Server Express for the backend. You can use Access forms / reports for the front end, linking the tables to the SQL Express Server.
I have done this type of split, but I only do it where there are VERY few people that would hit it at the same time. There's a copy of the database that houses all the UI things (forms, reports, etc) and the data lives in a different copy, all the tables are linked together. It works fairly well, but again I would NOT TRUST ACCESS with more than a few people hitting it at the same time.
I'll leave it to the rest of the SO community (assuming it gets migrated) to go from there.
Related
So here's the deal. I have a WPF application which stores all the data into MS Access Database. But it is supposed to be a multi-user based application.
What I want:
The application exe to run from each user node and get stored in the database present at a particular user's drive/location.
What I have Tried:
I put my application and access db file in a shared folder, and everything works fine. But I don't want my users to be able to copy the database. And according to what I researched and found, if I put any file on a shared location there's no way I can prevent anyone from copying it.
Considering the fact that I have negligible knowledge of Networking. I would like you to help me out with what I should search for, or the things that I should learn. Or if you could just provide the solution. Any help or suggestion is appreciated.
This is what I imagine it should be like:
Sorry, but this is not possible.
An Access database is just a file. Anyone with read access to that file, has, well, read access to that file, which allows them to copy it.
You can try to obfuscate the file location, but a tech savvy user will always be able to download the database.
You're looking for a client-server RDBMS. There are tons available (MS SQL, MySQL, Oracle, Postgres, etc.). In fact, it's much more common than databases like Access.
Alternatively, you can develop your own server that reads and writes to the database and passes data to the nodes and disallow nodes to directly access the database, but this is very much nontrivial and Access is not supported for server use.
I built an Access db which has a SQL Server backend. I have a stubborn and somewhat knowledgable user who will often go into the tables directly. I am attempting to stop this behavior.
The issue I am having is because he is a legitimate user of the database I had to give him read/write access to SQL Server so he could use the db like everyone else. However, no matter how I compile or hide panels at the end of the day all he has to do is open a new blank Access db, use his ODBC connection, link to the SQL Server backend using linked tables, and poof his read-write access allows him to edit tables directly.
Is there some way for me to give users read only or better yet No access what so ever to the SQL Server tables and still have the db function properly? "Properly" meaning users can make record changes like edit comments etc. Sort of like how a website works. The site itself has write access to the backend database and the user is just allowed to make changes using the GUI while on the site.
This problem is solveable only with significant application changes.
You could redesign your application to only use Stored Procedure for data access. No user (at least not the nasty one) has write permission on any table in your database. Every write operation is done via Stored Procedures.
This is a tried and proven approach to securing databases. However, it is used less nowadays because it requires extra efforts to make it work with OR-Mappers and other RAD-Tools like Access. If you implement this approach in an Access Frontend, you’ll have to implement every write operation to the database manually and thus are losing the main RAD advantage of Access.
Why is this user editing data in tables a problem?
If your database has a solid set of validation rules implemented with Constraints and Triggers and has proper auditing in place to know which user changed what, then this should not be a problem. You just let him do it, if he wants to.
But why is the user doing this at all?
If any user rather uses backend tables directly to read and write data, this indicates a massive usability problem with your application. Address the usability issues in your frontend application and the problem will go away while benefiting all of your users!
PS: The concept of application roles, which could be another approach to address this problem, does not work with Access. Access creates new connections to the database on its own. There is no possibility to activate the application role for these connections.
I had to give him read/write access to SQL Server so he could use the
db like everyone else
You can't both give him access and not.
The only way out is speaking to management to ask for formal rules and to tell users to follow these and behave.
Get your IT department to uninstall Access, install the Access Runtime and have him use your application that way.
I created a 2010 Access database for my team to use. Right now the database is in a shared folder on the server and everyone uses the same database file. I've run into some problems recently with the database auto-backing itself up and creating extra files (Database.mdb, Database1.mdb, Database2.mdb, etc). From what I can tell, I need to split the database into a front end and a back end and give each user a separate/local copy of the front end to interact with.
The way the company is set up, everyone uses a virtual desktop (built on Citrix). My team has a shared folder that everyone can access. I can't have everyone download a copy of the database to their local computer as we don't consistently use the same computers depending on where we are in the hospital. I don't have any access or authority to download a copy to each user's login. I don't have any experience with databases or CS/programming except what I taught myself to build the one for my team and I am having trouble understanding how splitting a database would functionally work when using a server like Citrix. Everything I have read assumes you have access to control how things are set up on the back end.
Say I split the database and store the front end in the shared folder so everyone can access it and store the back end in a separate location. Since everyone has a unique login to get onto the virtual desktop, does that mean that users essentially have a unique copy of the front end that they interact with even though everyone is accessing the file through the shared folder? Or is everyone still using the same front end?
If everyone would still be using the same front end, does it make a difference/is there a point to splitting the database? Would I be able to split the database and store the back end on my personal login ID or would I have to store it in a separate folder in the shared folder so that the data everyone puts in updates/saves to the database? If it's not feasible to split the database the way I am supposed to, is there another way to protect the data/files from corrupting?
Any help understanding this would be greatly appreciated.
One of the companies I work for still uses Access on a daily basis, so I feel your pain. With multiple users accessing the data at the same time, it is necessary to split your database to a front end and a back end. If you don't you will see a lot of corrupted databases. Once you deploy a front/back end, you will reduce the number of corruptions by quite a bit. It's just good practice overall to split your database
You shouldn't have any problems with multiple users accessing your front end. At the company I work for, they have front ends distributed to each persons desktop. There are a few users though that have to share the same front end though and they have never had a problem.
Once you have the database split, you can used the linked table manager to point your front end to your back end tables. I would suggest putting your back end in a separate folder.
Here is a decent write up of what you are wanting to do.
http://www.fmsinc.com/microsoftaccess/databasesplitter/
I am currently working on a project which has basically 2 users who will be the end users. Till now, we were using access as the front end but since the code was designed by an amateur, it frequently runs into some kind of memory problems and stops functioning on a regular basis. Now we have two options: redesign the access front end from scratch or probably try and build an excel interface.
All the data currently is stored in the sql server and we were only using access to input some text into it which was stored in access locally.
Please do let me know if you have any suggestions about creating excel as the front end. The amount of data stored in the sql server is about 6 table and 2 of them are really huge arnd 150,000 rows and 350 columns. these tables can be linked by unique keys. but ultimately for every unique key we currently have 1 row for it and end up writing comments on it and store and update the comments for further use. Ultimately the end user selects only about 300 rows and ends up editing it and closes it and moves to another 300 rows.
Also, since I am the only person who will be handling this, and the time is also very limited I am looking for a solution which will not be taking too much of my time to maintain the database later.
How is the Access database accessed? i.e. is it one file on a network share that is then used by both users? If so, that is your issue-- especially if both users try to use it simultaneously. That is almost always the cause of corruption on a mdb file. I absolutely agree with Chris that using Excel as a front end is a very bad way to go, however I don't know as you need to go all out with VB.Net. Access is very capable for simple applications when it's implemented correctly.
If multiple people are accessing an Access database, it needs to be "split" i.e. have one mdb file with all the tables and data (the backend) and another file with the user interface (the front end). The backend is placed on a network server or common location (but not dropbox) and is never directly opened. The front end is placed on each user's computer and is linked to the backend. If the database is not currently split, there is a wizard available that can help you do that.
You should be able to also link the same front end to anything in the SQL Server.
I have been using access for my applications from over 4 years now. I realize its time to move on now and i need suggestions for a new database. Here are my requirements :
Should be able to connect it with Vb.net windows form frontend GUI - all database functions such as add/delete/edit/update will be done through the vb.net front-end only.
Should be able to place the db on LAN and each client on the LAN can then access the centrally stored db through their individual front-ends.
At the most 5-6 users will be reading/writing to the database at the same time , so the database should not crash or slow down .
Since i come from MS access background, i would like something thats similar to it so that i can learn and adapt to it quickly.
Not very important, but i think its worth mentioning. This db will be the main central db for my .net application. My .net application will also be interacting with quickbooks and magento via some apis but ultimately all this data will go to the central db. So just curious, will there be any compataibility issues with the database that you suggest ?
Should handle about 10 tables and around 10k records in each table
Should be secure - just that i should be able to lock it up or anyhow prevent it being accessed from anywhere else other than the vb.net front-end.
Lastly, I would prefer it to be free to use if possible but not essential.
I realize there are some topics like mysql vs sqllite and on databases, but pls understand i need suggestions for one that will be apt for the purposes i have listed above.
All inputs will be greatly appreciated. Thank you!
Edit : Just curious - Would i pushing the limits if i still stick to access - i understand access won't be good for multi-user access but i guess 5 users is not much ?
I would go with SQL server express which adds no cost to your application. You would have to do some modifications to your application like double quotes that should be replaced by single quote. also note that any Ms access function in queries will not be compatible like date function. If you use msaccess form, you can still use them with the data from SQL server.
SQL Server is the obvious answer, and MS Access has built-in upgrade tools. I do not think you have to look further than that.
It sounds like the scope of what you're doing is pretty small, so I'd say using a new version of access (like 2010) is still a good solution. Access really only tends to start to struggle once you're building large applications inside it or having a large number of users. If you're under ten users I'd say it's still a fine solution.
Alternatively, SQLite is very similar to access in design and is a great database engine (and free as well!).