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.
Related
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/
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 developing a web application in Java EE technologies(Spring, Spring MVC, Hibernate). In this application I am parsing an Excel file and need to add these data to a sql server database.
Before adding these data to the database I need to get the user input for each row in the Excel file whether they really want to add these data to the database.
I can do this something like this:
First save the data to a table(table_tmp)
Then display the data to the user and from their input add it to the actual table and remove from the temporary table.
But I think there will be a better solution (some kind of temporary storage that I can delete after getting user input).
Can I use some NoSQL solution for this?
Why do you need to store it in the first place? You want to allow them to upload that excel, and come back way after their session expired and select rows they want? Do you really have to make it persistent?
If yes, then do you have any problems with your current setup? If not then you'll be introducing another external component that needs to be administered and that you have to interface with (what happens if mongodb is down, not enough disk space, connection timed out, ...) just to keep a temporary file.
But if you still want to do it, then you might first consider something really simple (and fast), like memcached - a key-value in-memory storage.
Suppose you have an database with the largest tables containing about 200.000 rows, and frequently modified. The client wants Excel to connect via ODBC to the database, and work as a frontend to manage the data. The data should be modifiable by up to 25 users concurrently.
My first instinct would be to recommend something else, for example a web frontend. But suppose the client insists on the Excel solution, would you regard it as doable, and what pitfalls would you see in it?
My doubts would be about:
data integrity (how to manage users modifying same data at the same time)
large amounts of data moved unnecessarily (when opening the Excel workbook I imagine that the whole database has to be transferred)
security (showing only parts of data to appropriate users in a secure way would be challenging - see previous point)
using a tool (Excel) for something, in which it doesn't excel (pardon the pun)
I do this all the time. No you don't have to bring in the whole database or even the whole table. I use ADO and VBA and send SQL statements via the Command object. For example, I have a royalty database with an Excel front end.
The user types in an invoice number and a SELECT statement retrieves that one record and populates some custom classes. The user enters/modifies some data and clicks 'Save'. Then the class has a method that writes the record back to the database with and UPDATE or INSERT depending on the situation.
At the end of the month, the user enters a date range and retrieves some records into a report, again just a SELECT statement filling some classes and outputting to a sheet.
Use Transactions so you can roll back if you hit any record locking problems, but with 25 users you probably won't.
At first glance I would suggest treating Excel a bit like a web page, that is, pull only the required data and use a specific form for editing that updates one record at a time via ADO. You need only lock a single record and that for the fraction of time it takes to update. You can check whether or not the record has changed since it was opened for editing and users can be told that they cannot open a record for editing and then leave it sitting around in the edit form or they may lose the changes.
It is usually quite unlikely for such a small group to need to change the same record at the same time.
I do not think you will have much trouble with 25 concurrent users.
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.