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/
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.
So I have tried doing some reading around and the closest I've come to an answer is Merging ACCESS projects (transferring a switchboard). I two .mdb files, one back-end that has data and one front-end that has forms, queries, and reports. I have a user who has been holding the SHIFT key to open up the linked tables on the front end and modify data.
What I've decided to do to counter this is create DAO connections in VBA to remove the linked tables. Then I'll create a .mde file to hide the VBA. Is that a smart move?
And with that I'll be creating a copy of the current database, modifying the front-end and back-end, and going live with it next week. What is the easiest way to bring in the newest data from the time I copy the database to the time I go live? I need all my new data, so do I just rename the old database to the new one and relocate it? Or do I copy and paste each table?
Thanks in advance
What you need to do is to edit your database to no longer allow the SHIFT key to function the way your user expects. Have a look at this Microsoft document on the AllowBypassKey functionality and how to turn it off.
You can also make it an MDE file (or ACCDE of you're using 2K7 or 2K10) so your user can't get into the front end in design mode, thus eliminating their capability to weasel into the back end.
Or have them fired for policy violations. :o)
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 a few questions about the architecture of a subscription service I am about to embark on and I am looking for some feedback on how best to set it up.
I won’t have a large amount of customers as Basecamp, maybe a few hundred and was wondering what would be a solid architecture for setting up the customer sites. I’m running SQL Server and .NET on a dedicated machine. Should create a new database for each customer as to have control and isolation of data or keep them all in one database?
I am also thinking of creating a sub-domain for each customer as well so modifications can be made to each site as needed. The customer URLs would look like this:
https://customer1.foobar.com
https://customer2.foobar.com
I am going to have the ability to ‘plug-in’ reports that will be uploaded to the site so each customer can customize as needed. Off the top of my head this necessitates having each sub domain on its own code-base for the uploading of these reports.
So on the main site the customer would sign up for their new subscription and I would programmatically create a new directory for the customer from the main code base and then create a sub domain pointing to the new directory for the customer and then finally their database.
Does this sound about right? Am I on the right track? How do other such sites accomplish the same thing?
Thanks for letting me bend your ear for a bit on this.
From a maintenance perspective, having a virtual directory for each customer scares me. Having done something similar, I would create separate domain pointers as you are intimating. Then you can check the referral headers to see what should be displayed. I would probably create one main site template and dynamically brand it for each customer. You can still create separate folders for customer specific reports or if you really need custom pages unique to that customer. I just wouldn't make each their own site.
The advantage of separate sites (including databases) is that the fate on one client isn't bound to all others. It'd be easier to upgrade (trial) to a sub-set before deploying to everyone else. The big issue here, as Scot points out, is time. You'd want to have things as automated as possible (and well tested), etc. It's also easy when a client leaves. You can always just back-up their database and send it to them (for example).
Auto-provisioning new sites and databases isn't easy, and the account that does that will need plenty of privileges - so your security testing will need to be better than usual.
A multi-tenancy approach is good for minimizing your time but you do have to be careful, you don't want customers data getting mixed up.
One approach that will work, within the one app (and database), is to make use of HttpHandlers (MVC framework, perhaps) so that some sort of client identifier is in part of the URL - but the folder doesn't have to physically exist (or virtually in the IIS sense). That way you don't have to worry about getting folder permission correct; but you do have to be careful about correctly identifying clients, their ids, and making sure clients can't make calls that use an id that isn't theirs.
https://www.foobar.com/[clientid]/subscriptions
The advantage of this is it's relatively straight forward: everything is in the application, and you don't have to worry about adding new DNS records, setting directory and/or database permissions, etc.
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.