Putting my .mdb online
OK I've read a few solutions, but I'm not sure what I need. My company uses Access to keep up with mostly everything. Products, orders, shipments, invoicing, you name it. However, we are spread out geographically and we don't have a windows server at my office.
So, I'm looking into putting Access online in some fashion so that we can all access the same data, but use Access itself as a frontend. I'm interested in knowing the best way to do this. Can I get a shared windows hosting plan with someone like ixwebhosting.com and configure the DSN to connect the online version to the not-online version? Or do I have to convert my database to SQL Server, upload it, and then somehow connect access to the online version?
The ultimate goal is to have just the DATA online where we can all access it. But I'm not knowledgable enough in PHP, ASP, or other languages to build an online application, so it seems that using Access as sort of a front-end would be preferrable. But all the talk of OLE DB, ADO, JET, SQL SERVER, ADP, etc...this is really confusing to me. I need some help understanding my options here and finding a solution. Web hosts are clueless as to whether or not they even support Access as a frontend as I've noted.
Please help?
So, I'm looking into putting Access online in some fashion so that we can all access the same data, but use Access itself as a frontend. I'm interested in knowing the best way to do this. Can I get a shared windows hosting plan with someone like ixwebhosting.com and configure the DSN to connect the online version to the not-online version? Or do I have to convert my database to SQL Server, upload it, and then somehow connect access to the online version?
The ultimate goal is to have just the DATA online where we can all access it. But I'm not knowledgable enough in PHP, ASP, or other languages to build an online application, so it seems that using Access as sort of a front-end would be preferrable. But all the talk of OLE DB, ADO, JET, SQL SERVER, ADP, etc...this is really confusing to me. I need some help understanding my options here and finding a solution. Web hosts are clueless as to whether or not they even support Access as a frontend as I've noted.
Please help?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Arthur I appreciate your helpful comments. A question though... when you said...
"You can then consider keeping the in-house Access application, connected to the SQL Server BE, and providing a Web version of the application (connecting to the same SQL Server database) for those users who are geographically distributed. This type of setup is very common. It is not, however, a simple matter of making the desktop Access FE available on the web. A Web-based application is quite differnt from a Desktop application."
...I think I understand you to say I can use Access to do its thing on my desktop, but it will update the DATA online so that those who use the web application will have updated data from my desktop. Why, then, could I not have these 3-4 other people use their own version of Access on their desktops and do the same thing you're suggesting that I do from mine? Is it not possible to have them do this simultaneously?
I do realize that the best approach is probably going to be a web application, but I don't really have enough skills now to create one. I will in the future as I'm taking classes when I can online. However - for an "intermediate" solution I would love for 3-5 users to be able to use Access as the frontend simultaneously.
Is this do-able? Or do I need to go ahead and commit to learnign PHP/MySql or ASP(.net)/SqlServer and forget having an "intermediate" solution?
~thanks!
"You can then consider keeping the in-house Access application, connected to the SQL Server BE, and providing a Web version of the application (connecting to the same SQL Server database) for those users who are geographically distributed. This type of setup is very common. It is not, however, a simple matter of making the desktop Access FE available on the web. A Web-based application is quite differnt from a Desktop application."
...I think I understand you to say I can use Access to do its thing on my desktop, but it will update the DATA online so that those who use the web application will have updated data from my desktop. Why, then, could I not have these 3-4 other people use their own version of Access on their desktops and do the same thing you're suggesting that I do from mine? Is it not possible to have them do this simultaneously?
I do realize that the best approach is probably going to be a web application, but I don't really have enough skills now to create one. I will in the future as I'm taking classes when I can online. However - for an "intermediate" solution I would love for 3-5 users to be able to use Access as the frontend simultaneously.
Is this do-able? Or do I need to go ahead and commit to learnign PHP/MySql or ASP(.net)/SqlServer and forget having an "intermediate" solution?
~thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
How many users do you have and how big is your MDB? How are you currently hosting your data if you don't have a Windows server.
Strictly speaking you don't have to go to the web. You can have your Access front end connect to your backend database over a wan and a VPN. However, new release deployment would be an issue for the front end code.
Access itself provides web capabilities for its database.
I agree that it would be better to switch from Access to some other more robust relational database but it would be job to convert all the SQL. The queries would probably also have to be redesigned to have most of the work done in the backend on the database server to minimize network traffic.
Strictly speaking you don't have to go to the web. You can have your Access front end connect to your backend database over a wan and a VPN. However, new release deployment would be an issue for the front end code.
Access itself provides web capabilities for its database.
I agree that it would be better to switch from Access to some other more robust relational database but it would be job to convert all the SQL. The queries would probably also have to be redesigned to have most of the work done in the backend on the database server to minimize network traffic.
" but it will update the DATA online so that those who use the web application will have updated data from my desktop"
Yes, by having both applications 'talk' to the same SQL Server instance.
tncbbthositg >>
"Your geographically distributed users can still access the sql server over the internet, but that's a pretty huge security risk."
What I was saying was to have both the Access FE for the in-house users and the ASP or ASP.NET or Dreamweaver Web pages talk to the same SQL Server Database. Not to have the Web users access SQL Server directly. There is no security issue in that case.
AW
Yes, by having both applications 'talk' to the same SQL Server instance.
tncbbthositg >>
"Your geographically distributed users can still access the sql server over the internet, but that's a pretty huge security risk."
What I was saying was to have both the Access FE for the in-house users and the ASP or ASP.NET or Dreamweaver Web pages talk to the same SQL Server Database. Not to have the Web users access SQL Server directly. There is no security issue in that case.
AW
I agree Arthur. You're absolutely right about that. The asker said, "the best approach is probably going to be a web application, but I don't really have enough skills now to create one." I was saying it's possible, but then again, it's also possible to kick yourself in the face, but that doesn't make it a good idea. The best bet would be to write a web app and have everybody use it. I see no reason to use an access front end internally, but a web app externally if teh web-app is written well enough.
TNC
TNC
Security can be accomplished by using a VPN with strong password protection. Although a web app is probably the right way to go, it would require much more of a rewrite and apparently a learning curve in this case.
ASKER
Thanks for the help. Arthur -I meant to put yours as the accepted answer and the other as assisted...but I messed up and can't undo. I did distribute the points correctly, though, so thanks again!
ASKER