Hiii,
I am planning on developing a intranet website using access as the database and .net as the front end
or
A windows application by using access as the both user interface and database
Can anyone tell me, whether we can upload a file or a document into the access database or not.
Yes, It is possible to store a document in an Acces file. The issue is mainly a volume issue. Access databases holding documents tend to grow veeeeeryyyyy fast. People usually prefer to use the database to store a link to a document, rather than the document itself.
The issue with the the large files is the overhead that OLE adds when storing in the database. Take a look at this MSDN Article for an example of how to read/write files.
If you want to take a look at the OLE bloating issue look at what these guys have done.
Related
I need to develop a very simple database (probably no more than 4-5 tables, with up to 50 records per table) for my company, with the following requirements:
The database itself (most likely an Access file) must be stored on a server and accessed through http://www.something.com/my_db.mdb
Users from 6 different countries (with generally low Internet bandwidth) must be able to access this database and to view / edit it through a few masks, as well as produce automatic reports / extracts
The whole solution must be as robust and as low-tech as possible, to reduce maintenance issues (ideally, no development at all)
I cannot pay an Access license for each user, and using OpenOffie or LibreOffice is not an option (because I cannot go and install it on the computers of all the users)
My first (and naive?) idea was to:
1) Create the mdb file containing only the data and store it on a webserver
2) Create the edition masks and the automatic reports in another file that would define the online file as data source
3) Deploy the file containing the edition masks to the computers of all users
4) The users only have to open their local file to edit the distant DB through ther edition masks
Is my approach somehow realistic? Do you see another approach that would make more sense? Can I implement my solution with 1 single Access license?
Thanks a lot in advance for your inputs and insights!
If you provide just the mdb file as file source, accessible via HTTP, the users won't be able to connect to the database, because in a HTTP GET file download they just get the .mdb file downloaded to their local computer. When they edit something within the database (e.g. add a record), it will be done just locally on their local copy of the file.
If you want to use a access database, the simplest approach I have is that you implement a very small web application (e.g. ASP.NET) which connects to the .mdb file (and the .mdb file then can be in a private directory on the server). Your web application then is deployed to Internet Information Server (Microsoft IIS as a webserver).
You can provide data forms as web application, which you implement using ASP.NET, or develop separate clients which access web services you develop with .NET.
You could try cloud based solutions like; Google Firebase
For a requirement of this type; one should not use Access tables which are static because Access is a front end database but instead use a back end database such as SQL Server Express. SSE is free and one is better positioned to provide real web based features if needed in the long run.
Further I would say, in terms of cost/management - one should really consider using one of the online db services such as soho, knack, airtable, etc. One of these could well be faster and less expensive than creating a web app from scratch for such a small requirement.
Apologies in advance if this is a dumb question, but with Google's release of "File Stream", does anyone know how this would impact MS Access dbs stored on it?
My "setup" is that I have users that are routinely using an AccessDB that was built for them years ago, and I'm trying to replicate it in MS SQL. Not by my choice, the file is stored by the clients on a Google Drive: Which essentially means that I can only look at the vba and do testing when the clients are not using it. The clients also use Google's sync to access the file.
So my question is two-fold. First, if the clients are looking to move to File Stream and asked how this would impact their ability to use the Access file (I have no idea). Second, will File Stream make it possible to have multiple users on a MS database without causing conflicts or problems? Would I still need to make sure that I have exclusive access to the file while making changes to the vba code?
Thanks in advance!
UPDATE: Over 1k visitors with the same question and updating the description as asked by the person who marked this as -1 (now marked -2 without feedback) but the only question answered is that having multiple users simultaneously isn't sound. What remains is why a single user scenario can cause corruption of the file stored on stream: Compact/repair fails at least when the file is large.
Based on experience, you need to make sure only one person has the database open at a time. If two people open the database, then changes will not be saved. Try to find a different solution if possible.
The MSAccess database engine is fundamentally based on the database primitives provided by the MS file system. Including the record read/write/lock primitives. (Bet you didn't even know that MS operating systems had a native database system!).
Access records and tables are NOT filesystem records and tables, BUT -- the Access database system of records and tables are built on top of the native system of record locking. (The native system doesn't, and never had, any thing smaller than file-level authentication and permissions, so Access built a whole new system on top).
That means that any file system, or any network file system redirector, which doesn't support record locking like the MS file system and the SMB protocol, can't support simultanous multi-user access to an Access database.
I'm not familiar with Google FileStream, but I assume that it's a way to access binary objects using a database API? Normally that means the API doesn't look inside the binary object: so it can't be locking individual sections of the file for R or W or RW: that means you can't R part of the object while somebody else W a different part: that means you can't share access. ... and even if File Stream means something different to Google, the chance that they support SMB inside it is slim to none, right?
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.
I am starting to create an MSAccess database, I have no Access experience - my previous experience is with MySQL and Oracle. Initially I had some difficulty coming to terms with the fact that MSAccess usually stores both the front end application and the Jet Engine database in the same file. It's different from what I'm used to. Plus the database will be shared over a network, and it just makes more sense to split the application from the data.
After some reading, I see that it is possible to store data in one file, and then link to the application elements in another file. Every article I've come across for this deals with splitting the database into two parts, after the database has already been made, and never discusses creating split database applications from the start. Is it because that would be a bad idea? I can't really imagine why, except that I've noticed that Access does not let me keep two database files open at the same time (it automatically closes one). So I am foreseeing a need to constantly to open and re-open files if I go down that route.
There is one practical reason why you might want to start with a single database. If you start with a front and back end file, you'll have to create tables in one database, then set up the link for each table manually.
This is not a big deal, but if you're just starting the system, you can save some busywork by developing the pilot system in one file, then splitting it. My assumption is you'll probably be making a lot of changes to the data structure at the outset; your work will go smoother if you're working in one file.
It is definitely a good idea to split the database before you deploy it to production. I'm not sure why you're having problems opening 2 Access files at once; this is not a restriction of Access.
You can create the two db files separately at the outset. I do that often. I seldom need both open at the same time in the Access interface. I only open the back-end database, which houses the tables, indexes, and relationships, to modify the design of those db objects. And those types of changes are relatively infrequent; most of the development workload is for the front-end db. To modify data in the tables, you can use the table links from the front-end db.
It is not a bad idea. You can have two files open at the same time, either open another Access instance or launch by double-clicking the second file. Make sure you have created a suitable back-end design before you start on the front-end.
It is more efficient to have it all in one file while you're alone to work on it. Once the database design is finalised, then you can split the db.
Splitting the db is usefull during testing as well: it allows you to reset your data to a known state in about 5 sec, just by copying a saved version of the back-end.
I have a website using ASP with an MS Access DB back-end for storing mainly blog posts. My company has a very long software approval process so I am stuck with what I have (i.e. I must use Access). I use server-side javascript to retrieve posts stored in the database using OLEDB calls. Everything works fine except that I cannot read any tables from the database when it is open in the MS Access program. The page displays an error message about the file being in use. This could lead to significant downtime while I am doing any work within Access. How can I make the file readable by my ASP application while it is open in Access?
Split the front end from the backend tables. Then when you open the front end it, it won't lock the database that has the database tables. This article has information on how to do this.
Make a copy for use by the web application. Make your changes in the original file, and then deploy it by overwriting the copy. You probably don't want to be making live changes in a production database, anyway. Wait until they are 100% baked.