- Local time
- Today, 07:08
- Joined
- Feb 19, 2002
- Messages
- 45,760
There is no conversion path from where you are now to the web.
1. If you want to convert to an Access 2013 Web application, you will need to RECREATE EVERYTHING except tables (those can be upsized - whoopty do). Forms are completely different and have different events. Reports are not possible at all. And VBA is not supported so your only option is macros which will probably not support all your existing functionality. And on top of that you need to purchase and install and maintain SharePoint or have it hosted for you at a service bureau.
2. If you want to go to HTML or other "native" web environment, again, you must start from scratch but this time you will need to learn a whole new language and development environment.
3. The simplest solution for an existing application is Citrix or Terminal Services. That will allow you to run the Access app on your server at work from anywhere. Since everything runs on the server and only keystrokes are sent to the server and screen pictures are sent back from the server, this is quite speedy. If you don't have a lot of users to support and you have a computer you can dedicate to the task, Terminal zervices is probably the cheapest solution. You set up the Boss' computer to allow remote connections and leave it powered up all the time (although, he can and should be logged off). Then he starts the remote session from his laptop. Some versions of Windows come with the Remote Desktop Client included and for others you need to purchase it. I think it runs around $125 per seat. Access doesn't need to be installed on the laptop because you are not actually running on the laptop. You are running the app on your server back at the office. Terminal services is only sending keystrokes and getting back pictures of the desktop in a browser window.
4. The final solution is to upsize the BE to SQL Server which you will have hosted by some service provider. Your Access FE can then connect to the SQL Server in the cloud. For this solution, the laptop needs Access installed and you need to distribute the FE to any remote user. This is the "middle" option as far as work you need to do. It is not hard to upsize to sQL Server but unless you have already used good client/server techniques with your forms and queries, you will have work to do to make the application function well. For a small database with only a few users, this option would run around $5 per month for the hosting.
Options 1 and 2 will cost thousands of dollars and take hundreds of man-hours for an application your size. Option 3 can be done in a few hours and might require the purchase of a couple of Remote Connect client licenses. Option 4 could take a few dozen hours depending on how quick you are and how much you have to change to make the app client/server complient plus the $5 per month for hosting the BE. You could actually try option 4 without making any application changes but you are likely to find it too slow.
Here's a link to the thread that prompted this FAQ. http://www.access-programmers.co.uk/forums/showthread.php?t=241226
An update prompted by another question - http://www.access-programmers.co.uk/forums/showthread.php?t=245035
Many people say "Access" when what they really mean is Jet or ACE. "Access" is the application development environment and can use ANY ODBC compliant data source. It is tightly integrated with Jet or ACE depending on the version and so the products are inseparable in the minds of many. "Access" uses Jet or ACE to store the objects you develop such as forms, reports, queries, etc. The data used by your application may also be stored using Jet or ACE. But it can also be stored using ANY ODBC compliant database engine such as SQL Server, MySQL, and Oracle.
Access(actually Jet or ACE) is not the best choice of database engine for a web application. You can do it via ODBC from ASP or any other platform that supports ODBC but performance would be better with SQL Server or MySQL. From ASP or other platforms, it doesn't matter what database engine you use as long as you get the SQL straight. So using Jet/ACE would be no different from the program's point of view than using SQL Server. But the SQL syntax will be slightly different since each RDBMS has its own syntax and although they are all close enough so that you can read them, they are not interchangeable. There is a difference with the hosting requirements. Not all services support Jet and/or ACE so you would have to find a service that supports Jet or ACE if that is what you end up using.
If you are using Access 2013, your integrated database engine is ACE but if you use Access to create a web app, Access will use SQL Server to store your data. It will NOT use ACE.
You need to be clear on where you are going with this project. Do you want an Access FE? Do you want it to be a client/server app or a web app? In any case, you almost certainly don't want an "Access" BE. All the bad things you will ever read about "Access" are written by people who are not able to distinguish Access from Jet/ACE which are completely separate products and can be installed without an Office license and do not require that "Access" be installed to run.
1. If you want to convert to an Access 2013 Web application, you will need to RECREATE EVERYTHING except tables (those can be upsized - whoopty do). Forms are completely different and have different events. Reports are not possible at all. And VBA is not supported so your only option is macros which will probably not support all your existing functionality. And on top of that you need to purchase and install and maintain SharePoint or have it hosted for you at a service bureau.
2. If you want to go to HTML or other "native" web environment, again, you must start from scratch but this time you will need to learn a whole new language and development environment.
3. The simplest solution for an existing application is Citrix or Terminal Services. That will allow you to run the Access app on your server at work from anywhere. Since everything runs on the server and only keystrokes are sent to the server and screen pictures are sent back from the server, this is quite speedy. If you don't have a lot of users to support and you have a computer you can dedicate to the task, Terminal zervices is probably the cheapest solution. You set up the Boss' computer to allow remote connections and leave it powered up all the time (although, he can and should be logged off). Then he starts the remote session from his laptop. Some versions of Windows come with the Remote Desktop Client included and for others you need to purchase it. I think it runs around $125 per seat. Access doesn't need to be installed on the laptop because you are not actually running on the laptop. You are running the app on your server back at the office. Terminal services is only sending keystrokes and getting back pictures of the desktop in a browser window.
4. The final solution is to upsize the BE to SQL Server which you will have hosted by some service provider. Your Access FE can then connect to the SQL Server in the cloud. For this solution, the laptop needs Access installed and you need to distribute the FE to any remote user. This is the "middle" option as far as work you need to do. It is not hard to upsize to sQL Server but unless you have already used good client/server techniques with your forms and queries, you will have work to do to make the application function well. For a small database with only a few users, this option would run around $5 per month for the hosting.
Options 1 and 2 will cost thousands of dollars and take hundreds of man-hours for an application your size. Option 3 can be done in a few hours and might require the purchase of a couple of Remote Connect client licenses. Option 4 could take a few dozen hours depending on how quick you are and how much you have to change to make the app client/server complient plus the $5 per month for hosting the BE. You could actually try option 4 without making any application changes but you are likely to find it too slow.
Here's a link to the thread that prompted this FAQ. http://www.access-programmers.co.uk/forums/showthread.php?t=241226
An update prompted by another question - http://www.access-programmers.co.uk/forums/showthread.php?t=245035
Many people say "Access" when what they really mean is Jet or ACE. "Access" is the application development environment and can use ANY ODBC compliant data source. It is tightly integrated with Jet or ACE depending on the version and so the products are inseparable in the minds of many. "Access" uses Jet or ACE to store the objects you develop such as forms, reports, queries, etc. The data used by your application may also be stored using Jet or ACE. But it can also be stored using ANY ODBC compliant database engine such as SQL Server, MySQL, and Oracle.
Access(actually Jet or ACE) is not the best choice of database engine for a web application. You can do it via ODBC from ASP or any other platform that supports ODBC but performance would be better with SQL Server or MySQL. From ASP or other platforms, it doesn't matter what database engine you use as long as you get the SQL straight. So using Jet/ACE would be no different from the program's point of view than using SQL Server. But the SQL syntax will be slightly different since each RDBMS has its own syntax and although they are all close enough so that you can read them, they are not interchangeable. There is a difference with the hosting requirements. Not all services support Jet and/or ACE so you would have to find a service that supports Jet or ACE if that is what you end up using.
If you are using Access 2013, your integrated database engine is ACE but if you use Access to create a web app, Access will use SQL Server to store your data. It will NOT use ACE.
You need to be clear on where you are going with this project. Do you want an Access FE? Do you want it to be a client/server app or a web app? In any case, you almost certainly don't want an "Access" BE. All the bad things you will ever read about "Access" are written by people who are not able to distinguish Access from Jet/ACE which are completely separate products and can be installed without an Office license and do not require that "Access" be installed to run.
Last edited:
