Migrate Access DB to browser-based on local network (1 Viewer)

Mike Krailo

Active member
Local time
Today, 17:31
Joined
Mar 28, 2020
Messages
634
...and 3) (and I hope this makes everybody smile)....I met a wonderful woman who happens to live very remotely at 8400 feet in Colorado and I'm looking to do some remote work at any level (pardon the almost-pun). Fortunately, while other services are limited up there - she does have excellent internet. LOL
Really nice place of beautiful nature in the Rocky Mountains but the cost of living there is 34% higher than most other places in the US. But congrats on your new female companion.
 

Zydeceltico

Registered User.
Local time
Today, 17:31
Joined
Dec 5, 2017
Messages
843
Really nice place of beautiful nature in the Rocky Mountains but the cost of living there is 34% higher than most other places in the US. But congrats on your new female companion.
Thanks! I moved to Pittsburgh from the very place she lives. I was out there for 9 years. Yeah - it's - pretty wonderful.
 

TedSla

New member
Local time
Today, 14:31
Joined
Nov 9, 2018
Messages
3

Zydeceltico, there's a lot of great advice in this thread. I've been through this scenario sooo many times. Twenty-five years with Access development, plus SQL for back-ends. Still dealing with 90-day wonders (IT guys) who create huge problems with their bias, especially, as seems to be your environment, top level ownership/management way over on the right-side of the adoption Bell Curve.

If you don't bail to the Rockies, sometime down the road please post a wrap up.
 

jampy

New member
Local time
Tomorrow, 05:31
Joined
Mar 29, 2022
Messages
14
Hi All,

I don't know how many times (over the past couple of years) I have written the next sentence (lol): I work for a steel manufacturing company in QC. I developed an inspection database in Access 2016 to collect our daily inspections and provide reporting on activities. The inspections take place on the floor via a 12" rugged tablet.

Well...I am happy to report that it has been a success. So much so that President of the company wants me to continue developing to include our other two plants and also add several more upper-management folks to the list of end users (mostly for reviewing reports).

Here's the thing, not everyone has MS Access installed on their computers and it is my understanding that the free viewer is no longer available and....and ....and

Which led me to looking at alternatives. It didn't take me long to come across the idea of a browser-based solution.

Fortunately, I am not unfamiliar with HTML, CSS and front end design although translating the Access tabbed forms I currently have will probably take some mental backflips. I also link the inspection forms to a library of part drawing files in pdf that can be recalled instantly. It's pretty slick if I do say so myself.

So, I'm trying to figure out what the best stack will be for me to undertake this new project.

Some of you may recall that the business rules here lead me to having an almost EAV type table design which I ended up not doing because the queries were going to be so cumbersome. I ended up with a hybrid model that works very, very well although I have the types of inspection spread across several tables that all share a master linking table.

Somewhere in the past couple of weeks I read quite a bit about JSON files and light bulbs started going off in my head that that might be a great way to capture inspection data that is sometimes minimal and sometimes many, many fields.

My few opening questions then are:

1) am I barking up the wrong tree thinking JSON datatype would help me achieve a more robust approach to the myriad type of inspections that need to be performed;
2) If so, what would that stack look like?;
3) If not, what other stack(s) should I be looking at?

I've been thinking MySQL, Python, and Angular (what am I missing?). Or MongoDB alternatively but a good bit of my DB is traditional RDBMS - although it appears that would be fairly straight forward to migrate into a new model in a robust environment.

I've attached a snip of my current table structure. There are several more look up tables but they're fairly extraneous to the current discussion although they would be needed. I think it is fairly obvious that I have some redundancy in the inspection table structure. That's the area I'm wondering if the JSON datatype would be beneficial and collapse all of those inspection tables down to one.

I'm looking forward to your thoughts.

Thanks,

Tim
Hi Tim,

did you post similar question on reddit a few mnths ago? I was discussing similar stuff there.

So let me introduce myself, I am Dean, Jam.py User and contributor. What I would suggest, take a good look at Jam.py. One really does not need to know anything about HTML, CSS and Web stuff. Just a bit of JS and Python is needed but only for ie reports. But that is the same with VBA. However, JS and Py one can use for any Web development, so it's a win-win. VBA just doesn't cut it for the Web.

From your diagram I'm 100% confident that YOU can build the Web App in less than 30 minutes! How about we bet on this? :)
Seriously, people did upload Access DB (not FrontEnd, BackEnd only), and got instant results on the web in less time. Sounds like an ad, but it's free so no one is making anything from it

On the pic there is a video "how to". It is a bit outdated since looks like they have made some improvements. If you go on root of this site, you'll find a standalone App. Standalone as no install, nothing, just run. Now, if your Boss does not like this, well...

I should say, Admins of this site, please do not get offended by me posting this. The interest in moving Access to Web is huge, and to be fair, I'm just providing info since I think Access is limiting me to provide current technology to people. Like right now, I'm struggling with Access and row_number! It is 2022 and still an issue.


Now, the question for Access (Office), how long does it take to install Office? On ie 10 Desktops? 20? 100? What is the cost?

If you like, I can allocate 30min of my time to help you out. You WILL have a POC in place. Than show it to the Boss and go from there.

Cheers

PS
So how might your App look like? How about this on a pic?

This is deployment on PythonAnywhere in less than 5 minutes. Just to expand on this a bit, the idea here is not to use PythonAnywhere as potential hosting. It is just an example how long it takes to deploy.
Also, I would like to stress one thing, for me, it is important to move away from HUGE providers like Google, MS, etc. I like mobility, so if some solution on the Net is needed for one single office, than really no need for Google or MS. An Raspberry Pi can be used as a server, we can't care less.

Oh, and BTW, Jam.py IS RAD (Rapid Development Tool). But just like Access for Desktops, it is used for Web Development, hence it can't do what Access does. So this is a development paradigm, it can't be really compared. Still, it is RAD.

D.



Hi All,

I don't know how many times (over the past couple of years) I have written the next sentence (lol): I work for a steel manufacturing company in QC. I developed an inspection database in Access 2016 to collect our daily inspections and provide reporting on activities. The inspections take place on the floor via a 12" rugged tablet.

Well...I am happy to report that it has been a success. So much so that President of the company wants me to continue developing to include our other two plants and also add several more upper-management folks to the list of end users (mostly for reviewing reports).

Here's the thing, not everyone has MS Access installed on their computers and it is my understanding that the free viewer is no longer available and....and ....and

Which led me to looking at alternatives. It didn't take me long to come across the idea of a browser-based solution.

Fortunately, I am not unfamiliar with HTML, CSS and front end design although translating the Access tabbed forms I currently have will probably take some mental backflips. I also link the inspection forms to a library of part drawing files in pdf that can be recalled instantly. It's pretty slick if I do say so myself.

So, I'm trying to figure out what the best stack will be for me to undertake this new project.

Some of you may recall that the business rules here lead me to having an almost EAV type table design which I ended up not doing because the queries were going to be so cumbersome. I ended up with a hybrid model that works very, very well although I have the types of inspection spread across several tables that all share a master linking table.

Somewhere in the past couple of weeks I read quite a bit about JSON files and light bulbs started going off in my head that that might be a great way to capture inspection data that is sometimes minimal and sometimes many, many fields.

My few opening questions then are:

1) am I barking up the wrong tree thinking JSON datatype would help me achieve a more robust approach to the myriad type of inspections that need to be performed;
2) If so, what would that stack look like?;
3) If not, what other stack(s) should I be looking at?

I've been thinking MySQL, Python, and Angular (what am I missing?). Or MongoDB alternatively but a good bit of my DB is traditional RDBMS - although it appears that would be fairly straight forward to migrate into a new model in a robust environment.

I've attached a snip of my current table structure. There are several more look up tables but they're fairly extraneous to the current discussion although they would be needed. I think it is fairly obvious that I have some redundancy in the inspection table structure. That's the area I'm wondering if the JSON datatype would be beneficial and collapse all of those inspection tables down to one.

I'm looking forward to your thoughts.

Thanks,

Tim
 

Attachments

  • Screenshot from 2022-03-29 10-44-29.png
    Screenshot from 2022-03-29 10-44-29.png
    204.2 KB · Views: 37
  • Screenshot from 2022-03-29 10-45-17.png
    Screenshot from 2022-03-29 10-45-17.png
    122.6 KB · Views: 39
Last edited:

Users who are viewing this thread

Top Bottom