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.
Related
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 know there are several questions similar, but I can't find one that answers my specific problem:
I need to save some data in a server for a game I'm developing.
Each user will save one binary file and some time after ask for it.
The file can be something between just a bunch of bytes to around 50kb.
A lot of questions (mostly about images) say to use the filesystem, because that file can then be served as static content. In this case that's not possible, since I will have to check somehow that I'm sending that file to the right user, and also I need some logic return the file only if it's not the same the user already has.
Should I save that file in the database or in the filesystem?
Note: The server will be hosted on Linux, and the DB will probably by MySQL.
Thanks!
I'm afraid you're far from providing enough information to answer your question correctly. If I read your question "naively", all you're trying to do is write a save game system.
In such a case, the file system is really all you need. DB are good for storing structured data that you're going to search, sum, combine and index, not for storing arbitrary bunch of small blobs.
Now, if there is other requirement, for instance, you're writing a web-based game that store the data for all players in a central location, the answer MIGHT be different (again, you need to provide much more details about what you're doing, though)
I suggest reading this whitepaper (To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem) by Microsoft research (it deals with SQL Server 2005).
The conclusions are - if the files are under 250kb, use the DB to store them
In essence,
filesystems seem to have better fragmentation handling
than databases and this drives the break-even point
down from about 1MB to about 256KB.
Of course, you should test for your own DB and OS.
I think you could user a sort of database. Filesystem is slow, cause it go on hard disk, move head to find file. With db, the access is faster. If your server is hosted on windows, you can use a microsoft db, access, that is little and fast.
I am planning the development of a photo gallery application for a client. I am developing the app in asp.net 3.5 and would like to develop it so that I can re-use the application across multiple platforms using various front-ends. Basically, I am wondering what are the dis-advantages and advantages of storing images in the database as binary files as opposed to simply storing the files in an application folder.
Any advice would be greatly appreciated!
Thanks,
Tristan
SQL Server 2008 supports FILESTREAM storage.
The files are stored on an NTFS volume like plain files, but are subject to transaction control and can be accessed via special file names passed to Win32 API functions (and of course any API built upon it) with additional SQL Server security checks (like GRANT options etc).
The disadvantage of storing as binary is that you blow the database size to incredible sizes. If you were to use an express edition of SQL Server, which is limited to 4GB per database, you photo gallery would "finish" quite soon.
The advantage is that you can easily manipulate the access restrictions per file and per user. You just look at user rights and decide whether you serve back the image or not.
File system storage will offer much better performance in saving and serving images, and is supported in every platform. If you can live without the security and transactional goodies you get from db storage, then I would go with the file system.
We had large LOB application that provided Bank tellers identification information about the member standing in front of them. Our textual data was stored in SQL Server. Image data was stored in files. The database field simply had a filename. This approach works well if you are behind the firewall. Reading and writing files is easy. The trouble is the file management. You should secure the file system so that random people cannot view the directory. Also, backups are more complicated with loose image files. You have to backup the database and the image files. The fields can reference paths that no longer exist. For example, some IT dude decides to move the image folder and now all the references in the db are broken. If your application needs to pass information through the firewall, I would suggest storing images in the SQL Server using the mentioned FileStream storage.
Storing the images in the database would have saved us some grief. We would have only had to backup the database, it would be more secure, the references would never break and we would not have had to jump through hoops to get files from network outside the firewall.
This debate has been going on in almost any SQL Server community for ages. there are good arguments for both sides and there is definitely not just one size fits all answer. It really depends on your individual situation and on many factors, such as number of users, avg. file size, update frequency, read/write ratio, disk-subsystem yadayadayada...
But as you mention SQLExpress probably the most important factor is the max database size limit and this is a very good reason to go for the filesystem approach. Anyway, this research paper might still be interesting for you: To BLOB or Not To BLOB:
Large Object Storage in a Database or a Filesystem?
This paper used to be on the Microsoft Research site here: http://research.microsoft.com/apps/pubs/default.aspx?id=64525, but that link doesn't work for me. SQL Server has come a long way since then. Quassnoi already mentioned FILSTREAM, for example.
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.
I have been hired to help write an application that manages certain information for the end user. It is intended to manage a few megabytes of information, but also manage scanned images in full resolution. Should this project use a database, and why or why not?
Any question "Should I use a certain tool?" comes down to asking exactly what you want to do. You should ask yourself - "Do I want to write my own storage for this data?"
Most web based applications are written against a database because most databases support many "free" features - you can have multiple webservers. You can use standard tools to edit, verify and backup your data. You can have a robust storage solution with transactions.
The database won't help you much in dealing with the image data itself, but anything that manages a bunch of images is going to have meta-data about the images that you'll be dealing with. Depending on the meta-data and what you want to do with it, a database can be quite helpful indeed with that.
And just because the database doesn't help you much with the image data, that doesn't mean you can't store the images in the database. You would store them in a BLOB column of a SQL database.
If the amount of data is small, or installed on many client machines, you might not want the overhead of a database.
Is it intended to be installed on many users machines? Adding the overhead of ensuring you can run whatever database engine you choose on a client installed app is not optimal. Since the amount of data is small, I think XML would be adequate here. You could Base64 encode the images and store them as CDATA.
Will the application be run on a server? If you have concurrent users, then databases have concepts for handling these scenarios (transactions), and that can be helpful. And the scanned image data would be appropriate for a BLOB.
You shouldn't store images in the database, as is the general consensus here.
The file system is just much better at storing images than your database is.
You should use a database to store meta information about those images, such as a title, description, etc, and just store a URL or path to the images.
When it comes to storing images in a database I try to avoid it. In your case from what I can gather of your question there is a possibilty for a subsantial number of fairly large images, so I would probably strong oppose it.
If this is a web application I would use a database for quick searching and indexing of images using keywords and other parameters. Then have a column pointing to the location of the image in a filesystem if possible with some kind of folder structure to help further decrease the image load time.
If you need greater security due to the directory being available (network share) and the application is local then you should probably bite the bullet and store the images in the database.
My gut reaction is "why not?" A database is going to provide a framework for storing information, with all of the input/output/optimization functions provided in a documented format. You can go with a server-side solution, or a local database such as SQLite or the local version of SQL Server. Either way you have a robust, documented data management framework.
This post should give you most of the opinions you need about storing images in the database. Do you also mean 'should I use a database for the other information?' or are you just asking about the images?
A database is meant to manage large volumes of data, and are supposed to give you fast access to read and write that data in spite of the size. Put simply, they manage scale for data - scale that you don't want to deal with. If you have only a few users (hundreds?), you could just as easily manage the data on disk (say XML?) and keep the data in memory. The images should clearly not go in to the database so the question is how much data, or for how many users are you maintaining this database instance?
If you want to have a structured way to store and retrieve information, a database is most definitely the way to go. It makes your application flexible and more powerful, and lets you focus on the actual application rather than incidentals like trying to write your own storage system.
For individual applications, SQLite is great. It fits right in an app as a file; no need for a whole DRBMS juggernaut.
There are a lot of factors to this. But, being a database weenie, I would err on the side of having a database. It just makes life easier when things changes. and things will change.
Depending on the images, you might store them on the file system or actually blob them and put them in the database (Not supported in all DBMS's). If the files are very small, then I would blob them. If they are big, then I would keep them on he file system and manage them yourself.
There are so many free or cheap DBMS's out there that there really is no excuse not to use one. I'm a SQL Server guy, but f your application is that simple, then the free version of mysql should do the job. In fact, it has some pretty cool stuff in there.
Our CMS stores all of the check images we process. It uses a database for metadata and lets the file system handle the scanned images.
A simple database like SQLite sounds appropriate - it will let you store file metadata in a consistent, transactional way. Then store the path to each image in the database and let the file system do what it does best - manage files.
SQL Server 2008 has a new data type built for in-database files, but before that BLOB was the way to store files inside the database. On a small scale that would work too.