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
