zelfanet
asked on
Access database online
Hello,
We use a lot of access databases and want to make them available to people in the field. What can we do to turn these into web pages?
We use a lot of access databases and want to make them available to people in the field. What can we do to turn these into web pages?
ste5an
I would opt form Access frontends with SQL Server backends. Keep the logic in SQL Server, then you can make simple access web forms for these views and procedures.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can't use your existing applications over the web. Even converting to SQL Server will not help. In fact, if your apps are created using old Access techniques such as filtering forms, a straight conversion of the BE to SQL Server will result in slower response even on your LAN. Access is optimized to work on a LAN whether the BE is Jet/ACE or some ODBC database. Just because you can actually connect to a remote database over the internet doesn't mean you should.
The best method to use existing apps whether the BE is Jet/ACE or ODBC, is to use RDP or Citrix. Both options (if you are running the server on your own LAN will work to allow local folks to continue to use the LAN and remote folks can connect via RDP or Citrix to the same database. If you don't host the RDP or Citrix server yourself, then every user must use RDP or Citrix. You can't have some of each.
Although some people have reported success using Azure with Access, they have written the FE to use disconnected recordsets, etc. They do not use bound forms and they certainly do not filter data locally. I have never had success with this and I think the reason is because I don't run my own Cloud so I have no control over optimization. With the cheap plans you get what you get and it isn't sufficient to run Access. I could never get any provider to simply let me try an expensive plan to see if it worked. They wanted a year's commitment which was going to run $1,000 + just to find out whether or not I could actually port an existing app.
The best method to use existing apps whether the BE is Jet/ACE or ODBC, is to use RDP or Citrix. Both options (if you are running the server on your own LAN will work to allow local folks to continue to use the LAN and remote folks can connect via RDP or Citrix to the same database. If you don't host the RDP or Citrix server yourself, then every user must use RDP or Citrix. You can't have some of each.
Although some people have reported success using Azure with Access, they have written the FE to use disconnected recordsets, etc. They do not use bound forms and they certainly do not filter data locally. I have never had success with this and I think the reason is because I don't run my own Cloud so I have no control over optimization. With the cheap plans you get what you get and it isn't sufficient to run Access. I could never get any provider to simply let me try an expensive plan to see if it worked. They wanted a year's commitment which was going to run $1,000 + just to find out whether or not I could actually port an existing app.
Well each case is a bit unique...it depends on what you really need and what you are willing to do.
If you want your current applications to work as they are then the above comments are right ...you either change the BE and you continue to use Access over WAN (needs radical redesign...it could take a lot of time )....or based on the BE change you start creating the Web equivalent of your current applications (depending on the complexity of your Applications it could take a loooot of time ).
The fastest solution is RDP/RemoteApp since you change nothing and just have the overhead of Terminal Server/Cals
Depending of how much work you need from the "people in the field" ...eg. simply viewing or very limited data entry you could get away by using simple Web pages that connect to Access (PHP has drivers for Access ...tested and working) and do the necessary work...
If you want your current applications to work as they are then the above comments are right ...you either change the BE and you continue to use Access over WAN (needs radical redesign...it could take a lot of time )....or based on the BE change you start creating the Web equivalent of your current applications (depending on the complexity of your Applications it could take a loooot of time ).
The fastest solution is RDP/RemoteApp since you change nothing and just have the overhead of Terminal Server/Cals
Depending of how much work you need from the "people in the field" ...eg. simply viewing or very limited data entry you could get away by using simple Web pages that connect to Access (PHP has drivers for Access ...tested and working) and do the necessary work...
Pat, I know it's possible to use a local Access FE with a SQL Azure BE, because we do it. Our forms are bound, not disconnected. Of course we optimized the application using known techniques (see Best of Both Worlds), but that isn't that hard. Using this method, we have the advantage of having one desktop and interaction with all our other Windows programs, which would be more difficult (or impossible) with Citrix, and lower monthly costs too.
I'm not saying that Citrix/RDP isn't a good way to go - it's certainly a viable option and we've done that too. But I think you're being too extreme by saying that local Access FE to SQL Azure BE isn't possible.
I'm not saying that Citrix/RDP isn't a good way to go - it's certainly a viable option and we've done that too. But I think you're being too extreme by saying that local Access FE to SQL Azure BE isn't possible.
Armen,
Do you run your own Azure or do you use a third party? As I said, I tried it several times with at least three providers when Azure first appeared and failed miserably. You could literally watch the pixels paint. Perhaps the situation has improved. As far as I am concerned, this is the ideal solution if only it would work. Also, I am using home grade rather than business grade internet so that doesn't help.
If you use a third party, please tell us who and what type of plan you have so I can try again.
Thanks
Do you run your own Azure or do you use a third party? As I said, I tried it several times with at least three providers when Azure first appeared and failed miserably. You could literally watch the pixels paint. Perhaps the situation has improved. As far as I am concerned, this is the ideal solution if only it would work. Also, I am using home grade rather than business grade internet so that doesn't help.
If you use a third party, please tell us who and what type of plan you have so I can try again.
Thanks
Hi Pat,
I'm talking about SQL Azure, direct subscription from Microsoft. Not sure what you mean about a third party - unless you mean my ISP. The application I'm referring to works across many connections - home (consumer FiOS), tethered with my phone, Starbucks, etc. The connections are all decently fast with fairly low ping, but not blazing.
I'm talking about SQL Azure, direct subscription from Microsoft. Not sure what you mean about a third party - unless you mean my ISP. The application I'm referring to works across many connections - home (consumer FiOS), tethered with my phone, Starbucks, etc. The connections are all decently fast with fairly low ping, but not blazing.
@Armen: What subscription level?
Using S0 (10DTU) even with 500 Mbit/s gets only "works". Some years ago, when I had a customer with a 1Mbit/s LAN, I was the same feeling of responsiveness.
Using S0 (10DTU) even with 500 Mbit/s gets only "works". Some years ago, when I had a customer with a 1Mbit/s LAN, I was the same feeling of responsiveness.
Hi Ste5an, we're using Standard S1: 20 DTU.
If you want to use SQL on the cloud like the one you have on you LAN is not going to happen plain and simple....but sit back for a moment and think ...do you really do you want to scroll through thousands of records...you just want to find that specific record and what it accompanies it...so instead of fetching 1000s of records you just need a handful of records ...with the only issue being those huge comboboxes...but wait...with a bit of planning ahead you could group them to groups of 100s or 1000s and the performance would be just great....