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 ...
Based on previous learning, I would absolutely agree with months. If I could do it in weeks, I need to get a job elsewhere. I don't have the time to devote 100% of my time to learning something new and still do my current job.
I appreciate all of the comments and guidance. I've had to think about a few things I originally didn't.
I appreciate all of the comments and guidance. I've had to think about a few things I originally didn't.
Adding to the good advice you already have.
There is no one 'best' platform. There are many factors to consider, so I suggest doing research on that.
It is definitely a very steep learning curve to transition from Access (or any desktop) platform, to web.
I've been building Access apps for over 30 years. Started learning web with Classic ASP about 25 years ago, then ASP.NET. Currently, switching to Blazor. Each change involves a significant time investment, not only learning the tech, but getting comfortable with it.
If you are sticking with Microsoft, then the language to pick is C#. The latest Microsoft web platform is Blazor, which does not support VB.NET.
As mentioned, you'll also need to use a server based back end, like SQL Server, MY SQL, etc. So, you'll also have that learning curve.
Everything done with your VBA code will be done differently. Some things, might be done in the back end via stored procedures or triggers. Others might be done with JavaScript or server code.
So, you've got a lot to consider. Might be best to hire someone who has the necessary skills.
One other thing to remember, it might be assumed that the web app would work the same on mobile devices as on a desktop browser, but that is not automatic. Adaptivity need to be purposely incorporated.
Regarding the presentation,
here is what including pivot.js library does to for example NorthWind Traders application:https://www.youtube.com/watch?v=2Vg399Ewb20&lc=Ugxnoy4d6g4XfrWae5J4AaABAg
It is not about learning the specific technologies in depth. It is about investing as little time as possible to gain maximum results.
For example, to use this library for the Web project, this is what needs to be added to index.html providing the project is jquery based:
<!-- jquery ui for drag and drop--> <script type="text/javascript" src="js/jquery-ui.min.js"></script> <!-- pivottable.js --> <script type="text/javascript" src="js/pivot.js"></script>The js is a folder for a specific framework, where these two files were downloaded from the Net.
The rest is related to the specific framework. Usually, it is a copy/paste from some other project, like in here only the table/column name was changed.It literally took 5 mins to get this running.
- The challenge is not to create the tables, the OP has it all. The challenge is to present them on the Web with "no" coding.
Sure you can. That's the whole point of the frameworks. You'll have to explain to me how you "It takes a few secs to create 500 tables with 500-1000 random rows.", "With no code at all"?
As for your challenge, I can do the same with a PHP framework in a few minutes.It all comes down to your project specifications/needs that determines what solution and technologies to invest in. They all have PROs and CONs!
Hi,
if I may, here is the script to create 500 random tables with 5-10 random columns:
import random import string import sqlite3 conn = sqlite3.connect('northwind.sqlite3') conn.execute("PRAGMA synchronous = OFF") conn.execute("PRAGMA journal_mode = MEMORY") c = conn.cursor() # Predefined SQL data types data_types = ['INT', 'VARCHAR(100)', 'TEXT', 'DATE', 'FLOAT', 'BOOLEAN'] def random_table_name(): # Generates a random table name return 'table_' + ''.join(random.choices(string.ascii_lowercase, k=5)) def random_column_name(): # Generates a random column name return 'col_' + ''.join(random.choices(string.ascii_lowercase, k=5)) def create_random_table(): # Choose a random number of columns (between 5 and 10) num_columns = random.randint(5, 10) # Generate the column definitions columns = [] for _ in range(num_columns): col_name = random_column_name() col_type = random.choice(data_types) columns.append(f"{col_name} {col_type}") # Generate the CREATE TABLE statement table_name = random_table_name() columns_definition = ', '.join(columns) create_statement = f"CREATE TABLE {table_name} (`ID` INTEGER PRIMARY KEY AUTOINCREMENT, {columns_definition});" return create_statement # Generate 500 random table creation statements for i in range(500): #print(create_random_table()) sql = "" sql = (create_random_table()) c = conn.cursor() c.execute(sql)
One does not need almost any Python knowledge. Politely ask ChatGPT and off u go.We can also ask to insert some random data. Even more, this is what it says:
Let me know if you'd like to customize this further or add more complex data generation!
It takes a few secs to create 500 tables with 500-1000 random rows. The file is 27Mb in size.
Here is a challenge, how long does it take to create a CRUD Web app POC with this 500 tables?
CRUD means create/update/delete option. With a Menu to select the table, and sort/search any data.
With no code at all 😀- My thoughts:
>Since I'm not a web developer, I have to learn from scratch (just like I did with
>Access MANY years ago). Starting with the forms would be a great place to start.
Absolutely start with the Forms. Because there is already an underlying database with all tables and relations.
The misconception is that this is a difficult task. It is not the Form one needs to worry about. It is the User expectation, as you say. Luckily, it can be almost identical.
>And, there is VBA code behind some of the fields that will update or fire
>something off based on what is entered. I'm sure that's all possible, but I don't >know where the best place is to start.
The VBA executing similar on the Web is called the Event. The Event on the browser is executed by JS.The JS can then use any technology, ie Python backhand to "crunch" the data passed to it by the browser.
That is the Server side executing btw. The VBA is not executing on the server, but the desktop.
All RAD supports a number of Events and a bit of JS/backhand language knowledge is needed. Not a rocket surgery. So you are basically looking for an Event driven product/framework.
>I know there are many options out there, but I need something that is not
>going to break my brain trying to make this conversion.
The fastest are specialised RAD products. Django for example is not specialised. It is a general framework. Also, you are looking for a Full Stack framework. MS Access is, let's say, a full stack product, because it's got all "batteries" to drive the development. PHP is a language, not a RAD tool. Hence, it is not providing a full stack framework. However, the products developed by the PHP are providing it.
Re. that anyone can get your data, or updating a website is different from updating Access FE:
- upgrading everything, so the complete application, with the database schema, is normally by click on "Upgrade". That is the modern approach. Not a single page, not a single table, but one click for everything.
- accessing data can be protected. Not only that the data can be protected but the single "row" of data, or even a single "field" can be password protected. Yes, viewing a single piece of information can be allowed only to Users with the password for that particular field in a row.
If we go deeper, MS Access might have hardcoded outgoing email server with the password in it. Imagine someone stealing it. It does not need to open the Access FE. It can be done by Wireshark, inspecting the traffic from Access. So, having 2000 Access FE spread around the country might be a concern.
>But, my question is...what language is the easiest to learn/maintain from ?someone who is used to working with VBA?
Difficult to advise on this. It is not the language where the problem is. It is the paradigm. This is exactly why Access devs are still with Access imo.
It is understanding that data does not live on your Desktop any more. So opening the Explorer and fetching the files as before is not the same as on Desktop.
JavaScript is needed. There is no around this I'm afraid. This is a Front End language the browsers understand. Not anything else. Now, the BE, the backhand easiest language is Python.
How to start? Easy. Install Python. Then do "pip install ..." of your chosen framework.
I'll repeat, nothing else is needed.
The chosen framework has all batteries included. However, if you absolutely have no knowledge of how to include JS libraries and how to use them, like Pivot.js which completely eliminates Access reports, well then don't expect a flat learning curve.
The rampup is measured in hours depending on Access FE complexity.
A skilled dev can create a POC in minutes. We are discussing creating Forms from the existing database, that's done automatically by the RAD framework as mentioned, just like Access does it. But sure, it is a browser, not a desktop, it is impossible to expect pixel perfect layout.
Hope that helped. - 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. - 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. - HI there,
Sorry for delay,
this was discussed in length in here:
https://techcommunity.microsoft.com/t5/access/moving-away-from-ms-access/m-p/1193940/highlight/false/page/4
This is my take:
- Access is RAD. Hence, better to stick with RAD product(s).
- Using some other product is just that. We all spent time to learn Access in year 1999.
- Modern products are absolutely the same on mobile devices, IF we want to present it in exact manner. Plenty of examples on above link.
- The complete development with modern products is happening within the browser.
- The 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 Web application is the same as with 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 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 no 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 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 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 C# or VBA. - HI there,
Sorry for delay,
this was discussed in length in here:
https://techcommunity.microsoft.com/t5/access/moving-away-from-ms-access/m-p/1193940/highlight/false/page/4
This is my take:
- Access is RAD. Hence, better to stick with RAD product(s).
- Using some other product is just that. We all spent time to learn Access in year 1999.
- Modern products are absolutely the same on mobile devices, IF we want to present it in exact manner. Plenty of examples on above link.
- The complete development with modern products is happening within the browser.
- The 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 Web application is the same as with 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 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 no 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 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 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 that C# or VBA. - 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!
