Forum Discussion
Transitioning From Access To Web Sites
I have a question for the individuals out there that are moving to a web interface from Access What it the best app/program to use to make the move from using Access to using web pages? I've ...
Thanks for the reply and suggestions. Just like everything else, it's constantly being updated.
Luckily, it's already on a SQL backend.
I'll look into the suggestions and play around when I have time (ha!).
Thanks again!
Luckily, it's already on a SQL backend.
I'll look into the suggestions and play around when I have time (ha!).
Thanks again!
HI there,
Sorry for the delay,
It was discussed in length, try searching moving-away-from-ms-access
- Access is RAD. Hence, better to stick with RAD product(s).
- Using some other product is just that. We all spent time learning Access in 1999.
- Modern products are absolutely the same on mobile devices, IF we want to present it in an exact manner.
- The complete development with modern products is happening within the browser.
- Security can be anything. The World is your oyster. Normally, it is about 20-30 lines of code to auth against SAML, using provided libraries. After auth, the roles take over.
- One does not need to be a Web developer. This is the biggest misassumption of all. They are all RAD tools. One does not need to be a C# developer, or assembler dev to use Access. It might help, but unlikely.
- The Forms are almost always automatically created by the RAD product, just like with Access.
- Accessing Forms or any other part of a Web application is the same as Access using roles, privs, etc.
- The RAD products almost always support using free libraries.
- Any RAD product is shipped with the source code. The power of the Web is exactly that, the source code. Sometimes, it takes minutes to find the issue in the source and fix it.
- There is no deployment on the Client machines, that's obvious. What is not so obvious is that in a large environment, ie 2000 machines plus, the installation on Client machines takes time and significant expense. The Web eliminates this, plus the safety of data.
- the databases are irrelevant with the Web RAD products. Almost all are supporting standard databases. The switch from one DB vendor to another is almost always transparent for the Web App. The Web app does not care what the Stored Procedure/T-SQL is.Finally, the effort in learning any Web RAD product will almost always require JavaScript or TypeScript, which is used everywhere. It is a fantastic investment for the future knowing some JS.Any Access App can be "migrated", or whatever semantics to use, to the Web in a very short time. Any.
However, I have found that people are not ready for that even if "short" learning time is needed.
Imo, this is due to the expectation of who will support the App after the hand over.
Well, this is where JS kicks in. It is way easier to find the JS developer than the C# or VBA.
Sorry for the delay,
It was discussed in length, try searching moving-away-from-ms-access
- Access is RAD. Hence, better to stick with RAD product(s).
- Using some other product is just that. We all spent time learning Access in 1999.
- Modern products are absolutely the same on mobile devices, IF we want to present it in an exact manner.
- The complete development with modern products is happening within the browser.
- Security can be anything. The World is your oyster. Normally, it is about 20-30 lines of code to auth against SAML, using provided libraries. After auth, the roles take over.
- One does not need to be a Web developer. This is the biggest misassumption of all. They are all RAD tools. One does not need to be a C# developer, or assembler dev to use Access. It might help, but unlikely.
- The Forms are almost always automatically created by the RAD product, just like with Access.
- Accessing Forms or any other part of a Web application is the same as Access using roles, privs, etc.
- The RAD products almost always support using free libraries.
- Any RAD product is shipped with the source code. The power of the Web is exactly that, the source code. Sometimes, it takes minutes to find the issue in the source and fix it.
- There is no deployment on the Client machines, that's obvious. What is not so obvious is that in a large environment, ie 2000 machines plus, the installation on Client machines takes time and significant expense. The Web eliminates this, plus the safety of data.
- the databases are irrelevant with the Web RAD products. Almost all are supporting standard databases. The switch from one DB vendor to another is almost always transparent for the Web App. The Web app does not care what the Stored Procedure/T-SQL is.Finally, the effort in learning any Web RAD product will almost always require JavaScript or TypeScript, which is used everywhere. It is a fantastic investment for the future knowing some JS.Any Access App can be "migrated", or whatever semantics to use, to the Web in a very short time. Any.
However, I have found that people are not ready for that even if "short" learning time is needed.
Imo, this is due to the expectation of who will support the App after the hand over.
Well, this is where JS kicks in. It is way easier to find the JS developer than the C# or VBA.