Call for thoughts about Access to Web (1 Viewer)

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
Hi everyone

Pls let me introduce myself. I'm Dean, an IT professional with more than 25 years in the industry.

What I'm after is help from this community. But, it's controversial, because some might think like an intruder or something :)

So, what we made is an automated Access to Web converter, based on Jam.py. What it does is automated conversion to sqlite3 (for now), moving data to sqlite3, and than one builds the App from it as Forms. Beautiful Forms and really fast. Doing Forms is simple. It can also be automated, however, than one would minimise the learning path which is not steep anyway.

I know you'll be jumping off chairs guys with "what will happen with my VBA?" :) Nothing. It won't happen. But the crazy thought is can that be moved in a reasonable time to Python for backhand, and JS for FrontEnd? Like, how much VB is there? What does it do? Did you already move some stuff from Access to SQLServer? If so, Jam.py fully supports SQLServer, so there you go. Solved. We "fire" the stored procedure from Jam just like any other event.

Because Jam is an Event Driven architecture. Which means everything is accessed by the API. In Access, the Button can run a code after single click. Same in Jam, that is called an Event there.

Reports are designed similar to Access. It takes like 30 mins to design a Template, and than some time to develop an Event which "fires" server-side Python procedure. An Event looks like this for a button:

function on_before_print_report(report) {
report.id.value = report.task.invoices.id.value;
}
Here we take the invoice ID from the table and pass it to report. Server side report than consumes it (30 lines of Python code or so), and produces the content.

So there you go. Super short intro.

As mentioned in a thread "Migrate Access DB to browser-based on local network" Jam is Rapid Application Development. Can it be used in parallel with Access, sharing the same database? Yes. They are even hoping to make it talk directly with local Access db, over odbc. On Windows of course.

What I'm after is some thoughts about this! Is it worth pursuing the idea of automated conversion?

Cheers

PS
Pic showing Forms and report. Everything seen on Forms is no-code, no programming at all. WYSISYG. The code is needed for report, custom authentication, obviously custom buttons (which this on the pics are not), etc. Like email sending, it's custom code.
The link on the pics is accessible.
 

Attachments

  • Screenshot from 2022-03-29 10-45-17.png
    Screenshot from 2022-03-29 10-45-17.png
    122.6 KB · Views: 249
  • Screenshot from 2022-03-29 12-10-47.png
    Screenshot from 2022-03-29 12-10-47.png
    61.9 KB · Views: 319
  • Screenshot from 2022-03-29 12-09-29.png
    Screenshot from 2022-03-29 12-09-29.png
    237 KB · Views: 329
Last edited:

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 18:47
Joined
Oct 29, 2018
Messages
21,358
Hi. Welcome to AWF!

Having an automated conversion is nice, but it needs to handle a wide range of scenarios. Maybe the more important question is whether migrating your environment is better than all or any of the other options available.
 

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
Cheers

Agreed. There is no magic bullet. It might not be migration at all. As mentioned, is Access App using MSSQL? Than nothing is stopping one to spend hundreds of hours studying particular framework like Angular, or spend 30 mins with Jam and have some, if not all data on the Net in read-only mode? Protected by username/password which is default and takes not time to set it up.

That is only one scenario. It is not about the migration tool tho. This is about Jam.py which is used after. And gets the job done just like Access.

But for sure we could make it fully automated. The question is would that make any difference? Because it seems to me that people are looking exactly for a magic bullet!

One example is this: people are uploading FrontEnd Access file. And wondering where is the data? That is what I see and it clearly says on the site: Don't do it.
 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 20:47
Joined
Feb 28, 2001
Messages
27,001
You asked a question about VBA. The issue is that VBA's use in an Access app ranges from 0 to intrinsically pervasive to the level of being sine qua non. It's all over the map as to how much it is used. Beginners? Not so much. Advanced? I had thousands of lines in my biggest Access app. There is also the issue of Macros, which we tend to downplay as our DBs get more complex, because Macro error handling is nowhere near as good as VBA error handling. (And there are those that would choke on the use of "good" and "VBA error handling" in the same sentence.)

You mentioned events. Button events are quite common in Access. But there are at least 50 different events within Access, some of them related to a form state before or after a transition of some kind. You have some events based on control states and transitions within the form. And some in reports. If your environment doesn't provide cross-over event support, a lot of Access apps will be unable to operate (conceptually).

If you think about it, except for the occasional case of a Public Function that can be called from a query, ALL VBA in Access is event code because MSAccess.EXE is the MAIN routine for that program. The VBA code, being interpreted, only gets semi-compiled.

In a sense, you are doing something like a language translator. Such things work fine as long as you have the vocabulary. But here is the real road block to answering your question as it relates to VBA. Since VBA is not compiled but instead is emulated, we don't know exactly what sequence of instructions is implemented. Therefore, evaluating a conversion is going to be problematic. I'm sure we could see what PYTHON would generate, but it is very clear that we will NOT see what VBA will generate, since it ain't machine code.

In essence, that invites an apples-to-oranges comparison.
 

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
Good conversation mate, thank you.
For sure the Access Events are way more different than on the Web framework. It does not translate one to one. Jam.py however has huge number of Events. Oranges, that is.

I'm puzzled with is that many times people dump the idea of moving Access to Web because the VBA won't work! Again, I do understand the issue of x000 lines and 20 years accumulated knowledge in it.

Are any people actually interested in this way of moving Access to Web? Simply put, there is no need to waste time on html, css, etc when 95% of the stuff with Jam.py is no-code or low-code WYSISYG. Is other 5% worth pursuing?

D.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 01:47
Joined
Feb 19, 2013
Messages
16,553
I'm puzzled with is that many times people dump the idea of moving Access to Web because the VBA won't work!
it really depends on what you mean by moving access to the web. If you mean simply that users can connect from anywhere, from any device (which supports remote desktop) with both FE and BE at the remote location, then the standard method of achieving that is to use terminal server or citrix. They don't even need access installed on their machine, and porting the FE and BE across requires no changes other than to relink the FE to the BE in the new location. Of course the BE can be pretty much any RDBMS. Yes there's a cost, but then there is with hosting websites.

If you mean so users can use a web browser as the interface (the FE), the question has to be what is the benefit? HTML and it's kin has less functionality than access/vba although I accept it does have some features that can be difficult to achieve in access, but countered by there are features in access that are difficult to emulate in html. Then you have to cater for all the different browsers out there and the frequent changes that occur which break things (but we also see that with windows updates).

Then there is the purpose of the app. Most access apps are for the sole use of a business or an individual or group of individuals to manage their business or hobby - in much the same way as Excel can be considered. It is not intended as a gateway for any consumer to interact with the company. So why do you need a web app?

OK, you can create an app that works for many businesses but in my experience it will only meet around 80-90% of the requirements as you can see with all the commercial apps out there. So then you are into the need for expensive customisation or the business has to change it's processes to meet the needs of the app. Potentially losing a USP's along the way or restricting the way a business works.

If you could 'click a button' and preserve your investment in an access app to convert to the web, then I'm sure there will be takers, but as Doc says, it is not an easy task. One of the benefits of VBA is being able to interact with other apps such as excel, word and outlook. Not sure you can do that with JAM.

With regards volumes, there are tens if not hundreds of millions of 'access users' out there. Of those, perhaps one million utilise this and other access forums. For the rest, either they are not actually using access or are very comfortable with whatever they are doing and don't seek help. Of the one million, perhaps a thousand are what I would call 'regular responders', typically those who have high levels of access/vba skills and have the time to spend helping others.

Is it worth pursuing the idea of automated conversion?
Why not take the MS 'Northwind' database and convert that? Northwind has some basic VBA, not much, plus some macros. It might give you a feel for what is involved - and report back what was involved, how long it took etc.
 

Isaac

Lifelong Learner
Local time
Yesterday, 18:47
Joined
Mar 14, 2017
Messages
8,738
Because it seems to me that people are looking exactly for a magic bullet!

Really?

Somehow I have a feeling that most very serious Access developers would have no interest in submitting their VBA code to anything that claimed to completely "convert" it. Mostly because they know it's not possible, and also would never trust it and would end up going over everything with a fine tooth comb anyway.
I would definitely fall in that camp and can't help but think many others would too.

There is just no way you can interpret the intent of vba code - and as CJ says, it involves a lot of client-side manipulation with desktop, folders, files, and other office apps - excel, etc. I doubt your browser-based system would be given the security rights to do any of that.
 

GPGeorge

Grover Park George
Local time
Yesterday, 18:47
Joined
Nov 25, 2004
Messages
1,776
Good conversation mate, thank you.
For sure the Access Events are way more different than on the Web framework. It does not translate one to one. Jam.py however has huge number of Events. Oranges, that is.

I'm puzzled with is that many times people dump the idea of moving Access to Web because the VBA won't work! Again, I do understand the issue of x000 lines and 20 years accumulated knowledge in it.

Are any people actually interested in this way of moving Access to Web? Simply put, there is no need to waste time on html, css, etc when 95% of the stuff with Jam.py is no-code or low-code WYSISYG. Is other 5% worth pursuing?

D.
Microsoft tried four times to "webify" Access, going back to the old ADPs in the early 2000's. All four were abandoned. In addition, the .Net framework offers it's own alternative, such as MVCs. They are still around, albeit probably not used as frequently.

In short, you have a hard sell ahead of you to get anyone deeply involved in Access development to take another, third party, attempt seriously.

As someone suggested, convert Northwind using your tool. Post it as a freely downloadable application, or host it for trials. People will respond more positively, I am sure, if they can actually see that work.
 

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
Really?

Somehow I have a feeling that most very serious Access developers would have no interest in submitting their VBA code to anything that claimed to completely "convert" it. Mostly because they know it's not possible, and also would never trust it and would end up going over everything with a fine tooth comb anyway.
I would definitely fall in that camp and can't help but think many others would too.

There is just no way you can interpret the intent of vba code - and as CJ says, it involves a lot of client-side manipulation with desktop, folders, files, and other office apps - excel, etc. I doubt your browser-based system would be given the security rights to do any of that.

Yes. Absolutely.

I have no idea why the conversation went into a VBA. And the interaction with the OS, files, Excel, etc.
This is exactly finding the magic bullet, correct? So there is a simple or not so simple code and heaps of other stuff and wondering how would that work on the net?


We can't compare one development paradigm with the other. What we can compare tho is data.

Seems to me that the data is the king. So here is a simple question, and lets not go into the RDP or Citrix, when someone needs some data from the database on the Net, how would you do it? (*)

It is simple question. The "Boss" needs some part of Access App exposed on the Net. Because of reasons. Of course I'm trying to "sell" you the idea of using Jam.py. Simple because why would anyone spent weeks and weeks in learning huge frameworks to present one or a few tables on the net in a similar fashion as Access?

I mean, is this not the reason why we using Access for the Desktops? Because it is "integrated" solution for the job? I really have no time to learn C++ to present Forms and interact with the OS. Hence Access.

What I'm asking is to help me with understanding the above (*) question! How would you do it!
If you are not going to do it tho, than it is not the question for you. But the Web developer who might be better suited for the job.

D.
 
Last edited:

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 18:47
Joined
Oct 29, 2018
Messages
21,358
Yes. Absolutely.

I have no idea why the conversation went into a VBA. And the interaction with the OS, files, Excel, etc.
This is exactly finding the magic bullet, correct? So there is a simple or not so simple code and heaps of other stuff and wondering how would that work on the net?


We can't compare one development paradigm with the other. What we can compare tho is data.

Seems to me that the data is the king. So here is a simple question, and lets not go into the RDP or Citrix, when someone needs some data from the database on the Net, how would you do it? (*)

It is simple question. The "Boss" needs some part of Access App exposed on the Net. Because of reasons. Of course I'm trying to "sell" you the idea of using Jam.py. Simple because why would anyone spent weeks and weeks in learning huge frameworks to present one or a few tables on the net in a similar fashion as Access?

I mean, is this not the reason why we using Access for the Desktops? Because it is "integrated" solution for the job? I really have no time to learn C++ to present Forms and interact with the OS. Hence Access.

What I'm asking is to help me with understanding the above (*) question! How would you do it!
If you are not going to do it tho, than it is not the question for you. But the Web developer who might be better suited for the job.

D.
Hi. I actually just helped someone add this feature to their Access database. Their database logs inspections and the results of those inspections for their multiple clients. He wanted to allow their clients to quickly check the status of their inspections (only the ones pertaining to their company) using their Internet browser. So, what we did was create a module to export the specific data set into an HTML file and store it on their NAS, which they then opened up to their clients (I don't have the details for that part of the solution, I was only responsible for automatically creating the web pages). They run the module once a week, so their clients get to see a new set of updated data every week through the Internet without using RDP, VPN, or Citrix. Does that count? Does it answer your question?
 

GPGeorge

Grover Park George
Local time
Yesterday, 18:47
Joined
Nov 25, 2004
Messages
1,776
Yes. Absolutely.

I have no idea why the conversation went into a VBA. And the interaction with the OS, files, Excel, etc.
This is exactly finding the magic bullet, correct? So there is a simple or not so simple code and heaps of other stuff and wondering how would that work on the net?


We can't compare one development paradigm with the other. What we can compare tho is data.

Seems to me that the data is the king. So here is a simple question, and lets not go into the RDP or Citrix, when someone needs some data from the database on the Net, how would you do it?

It is simple question. The "Boss" needs some part of Access App exposed on the Net. Because of reasons.
Hm. I distinctly recall that you introduced VBA in the first post.... VBA is central to the successful logic of a relational database application built with Access. NOT including it in the discussion pretty much invalidates it from the outset. Unless this new tool can successfully replicate the logic in the VBA in an accdb, it's not going anywhere. It doesn't have to be a one-to-one conversion. It does have to be equally effective.

Interaction with Excel and other files? That ability is CENTRAL to the success of Access as a database tool. So any tool that purports to move an Access relational database application "to the web" is going to have to account for that part.

Data is indeed the reason for all relational database applications. Your question is a fair one. " ... someone needs some data from the database on the Net, how would you do it?" First, by "the Net", I suppose you mean the data is available from some location outside the local network, i.e. via an internet connection.

That data storage can be materialized as a remotely hosted SQL Server, MySQL, SQL Azure or other server based database. And an interface which can consume that data is required. Indeed that can be a browser based application. It can also be Access running on the desktop. It can even mean something like PowerApps.

I've personally been involved in successful projects of such design for more than a dozen years. The largest were multiple Access FEs inside an organization, linked to either SQL Azure or a hosted SQL Server. In BOTH cases, the data in the SQL Server databases was also exposed via a web browser-based application. Not one or the other, both.

In other words, what you are proposing has value to the extent that you can simplify or accelerate the process by which a web browser based interface can be created to work with the data in that environment, whether or not it can or should compete with the Windows application, i.e. with an Access FE.

Hence, the request that you demonstrate that capability by converting an existing, well-known application like Northwind to work in a web browser based interface generated by your tool. Once that's established, and people have a chance to review and experience it, this moves beyond a "what if" discussion.
 

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
Hi. I actually just helped someone add this feature to their Access database. Their database logs inspections and the results of those inspections for their multiple clients. He wanted to allow their clients to quickly check the status of their inspections (only the ones pertaining to their company) using their Internet browser. So, what we did was create a module to export the specific data set into an HTML file and store it on their NAS, which they then opened up to their clients (I don't have the details for that part of the solution, I was only responsible for automatically creating the web pages). They run the module once a week, so their clients get to see a new set of updated data every week through the Internet without using RDP, VPN, or Citrix. Does that count? Does it answer your question?

This are static pages ;) Not quite sure how is this related to a live data? I mean, good for you, but this are plain reports.

Let's not forget, are you sure this was the Access database and not MSSQL?
 

GPGeorge

Grover Park George
Local time
Yesterday, 18:47
Joined
Nov 25, 2004
Messages
1,776
This are static pages ;) Not quite sure how is this related to a live data? I mean, good for you, but this are plain reports.

Let's not forget, are you sure this was the Access database and not MSSQL?
Rule Number one of Holes.

When you reach the bottom, stop digging.

TheDBGuy happens to be one of the most well-known and widely respected Access developers in the world today. As are most of the others participating in this discussion.
 

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
Hi George,

appreciate your time in answering. I know VBA is central. But this is exactly the same issue for any database out there. When there is a dependency on one technology it is super hard to move away from it and create dependency on the other technology at the same time.

However, this is a thread about moving Access to Web. This is when we need to drop our Desktop perception and interaction with the OS. That simply does not exist on the Web. There is no files interaction on IOS devices.

So when we agree that the only thing we have is Access data, or BE (ie MSSQL), what do we do? We need to stop thinking about the FE, and concentrate on "how". My question is how do you all do it.

Correct, the Net is World Wide Web.

I know all steps involved with the conversion. But I'm biased. Obviously because of my involvement in the project. Unfortunately, looks like I can't add links here, but have a look at the screenshots if you like.

What do you see is the Access DB converted. And what you see it automated FE.
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 18:47
Joined
Oct 29, 2018
Messages
21,358
This are static pages ;) Not quite sure how is this related to a live data? I mean, good for you, but this are plain reports.

Let's not forget, are you sure this was the Access database and not MSSQL?
Yes, they are static pages. That's what I got from your earlier statement quoted below.
Seems to me that the data is the king. So here is a simple question, and lets not go into the RDP or Citrix, when someone needs some data from the database on the Net, how would you do it? (*)
That's why I qualified my post with a question "does it count?" I mean, I was able to expose the data on the Net, right?
 

GPGeorge

Grover Park George
Local time
Yesterday, 18:47
Joined
Nov 25, 2004
Messages
1,776
Hi George,

appreciate your time in answering. I know VBA is central. But this is exactly the same issue for any database out there. When there is a dependency on one technology it is super hard to move away from it and create dependency on the other technology at the same time.

However, this is a thread about moving Access to Web. This is when we need to drop our Desktop perception and interaction with the OS. That simply does not exist on the Web. There is no files interaction on IOS devices.

So when we agree that the only thing we have is Access data, or BE (ie MSSQL), what do we do? We need to stop thinking about the FE, and concentrate on "how". My question is how do you all do it.

Correct, the Net is World Wide Web.

I know all steps involved with the conversion. But I'm biased. Obviously because of my involvement in the project. Unfortunately, looks like I can't add links here, but have a look at the screenshots if you like.

What do you see is the Access DB converted. And what you see it automated FE.
You are NOT moving "Access" to the web. I think that is the misperception which is the problem in a nutshell. What you CAN do is create a new web-based interface that interacts with the data in that environment.

I can, and have, done that with C#. You can visit a live web page here that is pulling the same data for display as the Access FE on my desktop which manages that data from the desktop.
1648608118491.png


This kind of hybrid application ain't something new in the world. Data stored in an accessible location can be consumed in a number of ways from a variety of tools. I have one Access application with the data in SQL Azure which is also consumed in a PowerApps application on my phone.

The main selling point of your niche appears to be a way to automate some part of the creation of that new, web-based, interface from the existing desktop accdb. Most Access developers are not in the market for replacing their Access FEs, which you seem to be promoting: "This is when we need to drop our Desktop perception and interaction with the OS. " We are willing to complement our tools when it makes senseto do so.

In reality there is no compelling reason to choose one or the other exclusively. Hybrid applications are not common, but they are not all that rare either.
 

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
Yes, they are static pages. That's what I got from your earlier statement quoted below.

That's why I qualified my post with a question "does it count?" I mean, I was able to expose the data on the Net, right?

Sure, if the report is what you are after. But the guys out there are not after this. They are after moving Access to Web.

We are all professionals and very skilled people. Looks like it is the development paradigm we have a problem with.

The question still remains, how would you do it? Did anyone actually visited the page visible on the screenshots?

Maybe this is not for you guys at all to answer or help with. Simply because of different paradigm. Meaning if it aint Access, I'm not going to touch it, not interested. That's cool, I'm ok with it. If it's not your cup of tea, that's perfectly fine. Thank you tho.

BTW, in my second post maybe I used wrong read-only statement. That is just an example. Read only does not mean reports. Read-only is a role, if one needs such a role.

Obviously, the automation does not do such a thing as roles or privileges. It is simple to find my movie on the yt, search for:
"How to publish MS Access Application to Web using Jam.py and SQLite3"

Again, people are uploading FE and expecting data to show up. I'm not talking small number of people. The service is running for a year now.

But the service needs you, since it is you guys who are Access subject pros. It is only you who can advice me about the issues. I'm sure you guys email MS when you hit the PowerApps issue. I do understand that, I'm doing it all the time, it's my job to solve issues.

So there you go.
 

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
You are NOT moving "Access" to the web. I think that is the misperception which is the problem in a nutshell. What you CAN do is create a new web-based interface that interacts with the data in that environment.
This kind of hybrid application ain't something new in the world. Data stored in an accessible location can be consumed in a number of ways from a variety of tools. I have one Access application with the data in SQL Azure which is also consumed in a PowerApps application on my phone.

The main selling point of your niche appears to be a way to automate some part of the creation of that new, web-based, interface from the existing desktop accdb. Most Access developers are not in the market for replacing their Access FEs, which you seem to be promoting: "This is when we need to drop our Desktop perception and interaction with the OS. " We are willing to complement our tools when it makes senseto do so.

In reality there is no compelling reason to choose one or the other exclusively. Hybrid applications are not common, but they are not all that rare either.

Cool, thanks George.

That in bold is nicely put, yeah, english not my native lang. Helps heaps when someone explains it really well. I understand you guys are not on the market, not selling anything, and not profiting either. Just hoping for help.

Correct, as mentioned, people upload FE in a hope that magically things will appear all together with the data. No, it will not. It can happen only with BE.

Not sure why I can't post links here as you do. Even reply with your post does not go through...
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 20:47
Joined
Feb 28, 2001
Messages
27,001
You complain that we keep going back to VBA code and somehow think that is unfair. No it is not. It is FACTUAL that advanced Access applications will often contain a LOT of VBA code to handle a lot of events and behavioral tailoring. Sometimes, little tweaks. Sometimes, massive code sequences. If your product cannot handle the behind-the-scenes code that we write to make Access do "special" things then it is the wrong tool for the job. You are - consciously or not - pushing a "one size fits all" solution in a world where for the last, oh, 40 years, I have learned that it isn't true. One size DOES NOT fit all. That is Orwellian in concept. You are seeking silken conformity in a sandpaper world. Coarse grit sandpaper.

Converting forms and reports - it's a piece of cake, right? Wrong - if you take into account that Access forms include events related to things either recently done or about to be done that relate to stages where it makes sense to have code tweak the data before progressing to whatever is next.

However, this is a thread about moving Access to Web. This is when we need to drop our Desktop perception and interaction with the OS. That simply does not exist on the Web. There is no files interaction on IOS devices.

No, it is NOT a thread about moving Access to the Web. It is a thread about you trying to sell us on your product.

We do NOT need to drop "Desktop" perception and the ability to interact with the O/S. You are right that there is no file interaction on some devices. Which is why we tell people that certain devices don't work for what they want to do. I think of "tools in the tool kit" as an important thing for a programmer. What you offer is a tool, certainly. But the problem with any tool is that you can mis-use it. If I've got a hammer, I had better be working with nails. If I've got a decent toolkit, I might find something helpful for those Cotter pins.

YOU need to understand that Access is a product that people use because it works correctly in an environment that can be complex to understand and difficult to use in constructing applications. If you want "simple" then take your product to kindergarten. The real world is more complex than that. In my experience, customers are the people who will teach you the true meaning of perversity.

I watched the U.S. Navy take a set of well-documented forms driven by ORACLE as a back-end. (Wasn't an Access front-end, but something with a similar concept made for mainframes.) Took them a year and a half just to get the web-based FORMS right. They had to convert all of the other stuff that was batch/SQL-oriented, too, and that took another three years. Yet this was a "simple" conversion of a batch/menu system to a web system with NO functionality changes. Didn't even change the table scheme, just the interfaces, from programmed menus to web pages. Over four years - and they had some automation to help with what they built. ('cause I provided them with some of it myself.)

Trust me, I've seen "intelligent conversion systems" many times. I've seen some of the strangest code I've ever seen that was supposedly written by intelligent people. There is one phrase that comes to mind based on that experience: Artificial intelligence cannot cope with natural stupidity. Ponder that one for a while before making claims about how much you can convert.
 

jampy

New member
Local time
Today, 09:47
Joined
Mar 29, 2022
Messages
14
Hi Doc,

first post has this:
"But the crazy thought is can that be moved in a reasonable time to Python for backhand, and JS for FrontEnd?"


It is NOT about me or selling anything. People are asking for this. Not me. People. There is a thread:
"Migrate Access DB to browser-based on local network" - and that got my attention.

It is George who hit the nail with his comment.

I still can't add any links here, so can't really demonstrate anything.
 

Users who are viewing this thread

Top Bottom