UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V < 1 2  (Go to first unread post)
   Reply to this topicStart new topic
> Web Dev & Other Languages    
 
   
jleach
post Jun 10 2020, 10:46 AM
Post#21


UtterAccess Administrator
Posts: 10,571
Joined: 7-December 09
From: St. Augustine, FL


To add a little bit to Frank's well thought-out reply:

On the topic of web development, there's two primary methodologies that a framework/platform (or collection thereof) may employ.

The first is where the front-end (the actual html, CSS and javascript) are completely independent of the backend ("Backend" in web development terms means anything running on the server, not in the user's browser). In this case, it's necessary to have an API hosted on the backend server that will receive requests from the frontend and process them accordingly. A Web API is essentially a website hosted via any flavor (IIS, apache, etc) that has no UI, but instead receives and responds to requests using data (typically JSON). The API is responsible for working with any other server-side things, such as database access. In this model, the frontend (the user site itself) communicates with the backend via ajax calls.

Typical frontend platforms that fall into this method are Vue, Angular and React (of the three, Vue is quite nice and has the lowest learning curve, Angular the highest).


The second primary method is where the server is responsible for generating html/CSS/javascript that will be send to the browser upon every new page request. In this method, there is no separate "frontend" as a standalone application. The server receives a request, generates html based on the request, and sends the html along to the browser for display. The most common platforms/frameworks that use this methodology are ASP.NET Razor and most PHP libraries. This method generally has a lower learning curve.

There are significant advantages and disadvantages to each, though we generally prefer the first method, all in all. On a complete side note, the general state of web development using "modern" platforms such as Vue, Angular and React is really a beast unlike anything else in programming history: the build tools, abstractions, dependencies and compilers/transpilers that these are built on to make them work is absolutely ludicrous, requiring a massive amount of complex steps and thousands (sometimes tens of thousands) of "loosely stable" libraries (see here, it's 100% nail-on-the-head). It's amazing that it works at all, but the vast majority of web application development is done this way nevertheless. I eagerly look forward to the proliferation of WebAssembly and stable tooling for it, as this current state of modern web development is akin to castles built in clouds and is in serious need of an overhaul.

(in contrast, jQuery is more of a library that aides in "regular" javascript/html/CSS programming rather than "platform" web programming, it as not subject to the same "build in clouds" stack of cards that more modern platforms are.. that said, jQuery is not used in these more modern frameworks and while at one point was the holy grail of javascript libraries is now considered to be "old" and not needed anymore for modern web dev)



On the topic of MS and programming outside of MS, just for the record, my practice does (and I have no qualms about it) use MS programming tools for the majority of our work (.NET, MSSQL, Windows servers, IIS, etc). While I wholeheartedly agree with sentiments of MS's changeability and instability in the consumer product lines (and I absolutely despise how it's handled these days, I hate MS consumer products with a passion, and it's very unfortunate that Access is part of this terrible paradigm shift in recent years), their development platforms (outside of Azure) are very solid and remain very solid. In more than 10 years using them we've not run into any sort of the issues that we're faced with daily in their consumer level products.

I could argue the point about using free open source software vs Windows (licensed) software. We've done both, and what you gain by not paying for MS's stuff, you lose in FOSS inconsistencies and integrations (e.g., all Windows stuff tends to act the same, but Linux stuff is put together by thousands of developers with no cross-standards between them, and it's not the easiest to deal with in many cases). Anyway, again pros and cons to each.

Cheers,

--------------------
Jack D. Leach
Founder & CEO
Dymeng Services Inc.
Business Software Solutions
Go to the top of the page
 
FrankRuperto
post Jun 10 2020, 11:30 AM
Post#22



Posts: 1,099
Joined: 21-September 14
From: Tampa, Florida USA


Well said, Jack. Can we create a new thread for this topic?... e.g. "Considerations For Converting A Desktop Access App To A Web App".

Server database engines don't have the issues with corruption that a native Access backend has, even with Access as the front-end. In fact, Access makes an excellent front-end to a server DB using ODBC.

If users wants a completely internal web browser-based application, a web app may be overkill.

A web application requires these components on the server:
1. Web server. The web server accepts requests and serves up html and JavaScript. The web server can be local or hosted.
2. PHP, .NET and many other languages are added on top of the web server. Multiple languages can be used at the same time. PHP responds to .php files while asp.net responds to aspx files, etc.
3. Database server. A database server is optional for web apps, but required if you plan to create a truly useful application.
4. CSS is one or more files that live on the server that get included with the HTML to make the page beautiful and more user-friendly.

The client side can be developed in one or more of the of the following:
1. Web browsers. A web browser is to web apps as MS Access is to an Access front-end file. It's the underlying run-time environment that interprets HTML, CSS and JavaScript to do useful things.
2. Python, .NET or any other language that can handle http requests can be the client front-end programming language.
Using CuRL, even Access can be a web client application. One of our developers actually created an interface between Access and TextMagic using CuRL.
3. The terminal can also be a web client.

As a preface to moving away from Access, here's some things to consider.

Many Access applications are initially developed by the person in the office that knows Access exists. That person isn't necessarily a developer of databases or applications so most of their development can be improved. This and Microsoft's attitude regarding Access can give everyone at the organization the impression that Access isn't a capable development solution. Most Access applications can be made to work properly by an experienced Access developer.

Access is a true Rapid Application Design (RAD) tool. Developing an application in Access takes significantly less time compared to any other language. Access has the advantage of being database-centric and it has simple GUI controls that are geared towards databases. Other development languages are more robust but that means there's more to do. As an example, a text box control in Access has several default properties that make it work just by plopping it on the design surface. The same text box control in other development languages don't necessarily have any default properties so the developer has to control all properties. Additionally, a language like Python can be developed in a text editor. There are GUI designers but they are separate from the code environment. .NET has a visual designer but .NET applications are also extremely bloated.
Another surprise for the organization is that the days of developing and modifying their own application are over. It takes months to learn a new development language and the person that developed the Access application doesn't have the time or the desire to learn a new language.

Here's some recommendations.

For an organization that's just looking to replace MS Access, We recommend Python and GTK+ for the application and PostgreSQL for the database engine. There's plenty of other options, its a matter of taste and what you may already know or comfortable with. There are so many working parts in a web application that it's more difficult to manage and shouldn't be a first choice.
Python can make Windows API calls and there are libraries for working with Office documents. There's probably a more suitable way to do the same things using Python libraries. Another thing to consider is that if you use Microsoft APIs your application is no longer portable. If you use the Python library that allows you to manipulate Excel documents without using Excel, your application will remain portable. If your application uses the LibreOffice library, you can create ODF's (Open Document Format) XML-based documents that Word can read.
GTK+ is the Gnome Tool Kit. It's a set of widgets (controls) like text and combo boxes. Microsoft Forms is the Microsoft equivalent but GTK+ has more widgets. If budget allows, there's also Tkinter and Qt for widgets. All of these are cross platform.
Even though we recommend Python and GTK+, there's also .NET, but the big drawbacks are price and if the user is trying to get away from dependency of Microsoft products in the first place. With regards to price, practically every add-on (such as fancy, complex and colorful controls) come with an additional price and a license that can be easily lost by the organization or that is controlled by the developer. As a developer, would you want to pay the hefty fees for additional controls that might only be use with a single or a handfull of clients?
The PostgreSQL db server can be installed on a server or workstation machine and on Windows or Linux. There is no upgrade path because you get the full version from the get go. It's also open source and free to use.
Reporting can be done using Python libraries or even a report server. There are both open source and commercial solutions available. This would be the most likely piece of the application that would require commercial software.
An organization could still use MS Access or Excel for ad-hoc queries and reports. This gives them the ability to create a report at the time it's needed. If they plan to reuse the report it can be added to the Python application.

If the organization both wants to move away from Access and present their application on the Web, we recommend a web application (Apache + CSS + PHP + JavaScript (and JQuery/JSON/AJAX) that uses a web browser on the client side. If a browser is to limited in functionality then use a Python application. If the Python application needs to work on mobile devices, as well then use wxPython instead of GTK+ (though GTK+ may be mobile device friendly these days).

One other option are frameworks like WordPress and Joomla. These solutions have to major issues. The first is that the solution wants to control the database. You cannot customize tables without the potential of breaking the solution or an update to the solution destroying your table. Add-ons are also an issue. There are tons of them available, for a price. It's also difficult to choose the right one because you have to create something for testing in a short trial period. Customizations are possible but, once again, an update to the add-on could remove all of your customizations. These solutions are good for situations where customizations aren't required.

I hope this all makes sense.Lets move this to a new thread, I have a bad habit of hijacking other memebers topics lol, thanks.

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
jleach
post Jun 11 2020, 06:27 AM
Post#23


UtterAccess Administrator
Posts: 10,571
Joined: 7-December 09
From: St. Augustine, FL


Split to a new thread

--------------------
Jack D. Leach
Founder & CEO
Dymeng Services Inc.
Business Software Solutions
Go to the top of the page
 
FrankRuperto
post Jun 11 2020, 09:26 AM
Post#24



Posts: 1,099
Joined: 21-September 14
From: Tampa, Florida USA


Thanks for spliting this discussion into a new thread thumbup.gif

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
GroverParkGeorge
post Jun 11 2020, 10:15 AM
Post#25


UA Admin
Posts: 37,482
Joined: 20-June 02
From: Newcastle, WA


Disambiguation as almost always a good practice; ambiguous references tend to be less stable. It falls under the general rubric, "just because you can, doesn't mean you should."

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
bobalston
post Jun 11 2020, 02:43 PM
Post#26



Posts: 107
Joined: 12-October 04
From: Dallas area


I am a long time Access developer and also wanted to find a way to "move Access to the web". You can't. I spent some time reviewing various web development systems offering low code development. Since you seem to like php and Windows independence, I recommend you look at PhpRunner (https://xlinesoft.com/phprunner/). It creates nice straightforward web pages for search,select, view and edit right out of the box. You can be running a simple app in minutes, if you already have the database design and tables created. There are LOTS of customization capabilities and the option of inserting Php code at various events. You do need to work within the overall design of the app and do not have complete customization ability. But it can be much more than just a templated add/update/View/Delete system. It provides a straightforward logon and security mechanism. Support by the vendor is quite good via their forum and also their facebook page - https://www.facebook.com/groups/121465711664 - which is very active with Q&A. Even supports build web apps suitable for phones and tablets.
You can run and test inside their app using a built in web server. Also works well with the free XAMPP which provides Apache server and much more

If you want a VERY powerful web development tool, that can generate systems with C#/ASP.net for Windows or Java (Linux) look at Instant Developer - https://www.instantdeveloper.com/en/ - from an Italian company.. It is amazing in its capabilities. A significant learning curve but well worth it if you want to build web apps with lots of flexibility in your design.

I have licensed both.

bob
This post has been edited by bobalston: Jun 11 2020, 02:50 PM
Go to the top of the page
 
AlbertKallal
post Jun 11 2020, 04:16 PM
Post#27


UtterAccess VIP
Posts: 3,101
Joined: 12-April 07
From: Edmonton, Alberta Canada


QUOTE
the build tools, abstractions, dependencies and compilers/transpilers that these are built on to make them work is absolutely ludicrous, requiring a massive amount of complex steps


I agree.

However a few things:
First, .net (asp.net) is actually rather compact. We had a good compiler and tight code for 10+ years.

Stackoverflow was written in .net. And it allows the whole she-bang to run on a single 4 core server.

Take a look at a compiled .net application. The .net .dll's are super small.

As for SQL server express and scaliblity? Gee, 50 users can hammer away all day - it not break into a sweat. I have SQL express running 4 major applications and also serving the web server. Several 100 tables - lots in the 1 million + rows. I can't think of a applcation unless really "major" that SQL express will not handle.

As for the frameworks? We REALLY REALY are waiting for that web "rad" tool.

And as for a Ford vs Chevy discussion (and which is better?).

Well, coming from Access?

I expect a decent programming language. Something at least as good as VBA, and these days somewhat better.

combo boxes, data grid, listbox? They should all have a data bound ability. The idea that you write some loop to fill a combo box, or loop to fill out a grid of data is a step backwards to the dinosaur age. This is where the .net and asp.net really shines.

Visual Studio is free - and it darn good.

You also get a web control event model VERY similar to Access. So, in terms of learning curve?

asp.net + vb.net is quite much the smallest learning curve I can think of right now.

And I never could grasp why people note that you code oh so different in .net as opposed to VBA? Really? Never noticed the differance!

I mean, lets fill a combo box on a web form, shall we?

Ok, drag a combo box from the tool box to the web form (hum, just like in access).

Ok, now lets fill it:

CODE
        Dim rst As DataTable

        rst = Myrst("SELECT ID, HotelName from tblHotels ORDER BY HotelName")

        Me.DropDownList1.DataSource = rst
        Me.DropDownList1.DataBind()


So, this was drag and drop. (like Access).

I wrote code - really hard to tell the difference from VBA, or in this case VB.net

Ok, now after we select the combo box, lets for fun put the result in a text box.
Ok, drag a text box on the form.

Now, gee, I wonder if there is a combo box after update event like access? Yup - double click and I am in the VB code editor.

Sure feels like home. Sure feels like I did not learn much of anything.

I'll write this:

CODE
    Protected Sub DropDownList1_TextChanged(sender As Object, e As EventArgs) Handles DropDownList1.TextChanged

        Me.TextBox1.Text = Me.DropDownList1.SelectedItem.Text
        Me.TextBox2.Text = Me.DropDownList1.SelectedValue


    End Sub



You get this:




Gee, I even used "me." just like Access.

So, ok, if these other frame works are all so fantastic, and have a easy learning curve. Since looking at above, I did not touch HTML, wrote VBA like code, and used drag + drop.

The only "extra" bit of code is my "MyRst" bit of code. I wrote that since I was tired of writing + setting up the connection string. But that code routine is only a few lines of code. Wrote it years ago - still using it!

Is there really something less work, less learning, and easier then the above code in asp.net? I did not even have to much switch gears - been working in Access and SQL server all day. So, a 5 min break, and I fired up Visual Studio - dragged a few controls on a form, and I have a working web page with a combo box.

Ok folks - show me yours! I open to other web development tools, but you have to convince me that it going to be easier then the above, and I hard pressed to remember that I did anything different then when building a Access form.

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada
Go to the top of the page
 
bobalston
post Jun 11 2020, 05:52 PM
Post#28



Posts: 107
Joined: 12-October 04
From: Dallas area


@Albert

To me one of the attractions of Access was the ability to build applications with minimal code. Drag and drop, select options, etc. I think that is what I and others looking for an Access-like web application environment are looking for.

Bob
Go to the top of the page
 
AlbertKallal
post Jun 11 2020, 06:19 PM
Post#29


UtterAccess VIP
Posts: 3,101
Joined: 12-April 07
From: Edmonton, Alberta Canada


QUOTE
I think that is what I and others looking for an Access-like web application environment are looking for.


It needs that + a great and easy programming model. I strong believe that the industry is close to producing such a product.

Do keep in mind that the above asp.net example code was all drag + drop, and the event model is "similar" to Access.

However, to do a really great job, then quite a bit of work is required with asp.net. But it is quite easy to start building some easy forms.

But, it still a pain to pull and write data to and from tables. I have written a few "small" helper routines in asp.net, so now I can quite much drop a bunch of controls on a web page, call one routine to fill out the controls, and another routine to "save" the controls data back to the table. So as I go down this road, I am writing less and less code and moving closer and closer to a access like experience when I do web development.

So what I posted above is rather easy, and really was no different then doing this in access. (no more effort either).

However, a complete easy to use package is certainly not what I would "term" asp.net and vb.net. It has the most gentle learning curve I can think of, and you can do near anything you want. However, to get a nice look and feel, and to code up forms is STILL way too much work. So dropping some controls on a web page?
asp.net is really nice, but to get a full application look and feel is absolute tons and tons of work compared to access.

The industry is ready for that product. I just not found anything remote easier then asp.net - but I am waiting!!!

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada


Go to the top of the page
 
FrankRuperto
post Jun 11 2020, 06:51 PM
Post#30



Posts: 1,099
Joined: 21-September 14
From: Tampa, Florida USA


QUOTE (Bob)
To me one of the attractions of Access was the ability to build applications with minimal code. Drag and drop, select options, etc. I think that is what I and others looking for an Access-like web application environment are looking for.

Zoho, QuickBase, AirTable, etc. were supposed to be the answer, but the problem is that all the companies that create these tools want you to use their cloud and pay a subscription. There's a ton of free open source tools for building rich solutions, but there's a learning curve involved. Also keep in mind that with RAD, Low/No-Code app building tools there's less ability to customize solutions. If it hasn't already happened, I predict a huge company like Amazon will come out with the kind of tool we're looking for.

ADDENDUM: The following is my perosnal opinion and observations: In the eyes of Microsoft, COM is ancient tech and they're retiring COM through attrition. This means in the near future Office will only be available as an online version, and we all know MS has failed 4 times to provide a decent online Access version. MS has been struggling with Desktop Windows 10 and Desktop Office to the point that they've become brittle, unmanageable and support is killing them, so don't be surprised if Desktop Windows and Desktop Office is on the chopping block. We will probably start seeing them market thin-client workstations similar to ChromeBooks. Its funny how we're accelerating to a centralized cloud timesharing architecture. My first experience with computers was in 1969 at grade school. The math class had a Teletype ASR33 terminal that connected to a GE Mark I Timesharing system in Dartmouth MA with a 300 baud acoustic modem. We developed BASIC programs as homework assignments. The on-premise computers around were the IBM360, System 3 with 96-hole punched cards, DEC PDP8's, etc. Too expensive and too big for a personal computer. So the Timesharing "Cloud" world was the only affordable solution in that era. 35 years later, little did I imagine the industry would be heading back to the centralized, cloud, lease software on a subscription model. History repeats!
This post has been edited by FrankRuperto: Jun 11 2020, 07:35 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
CBAtUtterAccess
post Jun 11 2020, 08:28 PM
Post#31



Posts: 1
Joined: 11-June 20



Let me add to this discussion, especially about moving to the web and having that awesome RAD tool.

I have been using a PHP RAD tool called PHPRunner for many years. Maybe it's against the rules to promote it. All I can say is... I'm not really a web developer, I've learned some PHP. This tool, yes, is pretty much one of those "too good to be true". It costs money, yes. It doesn't do EVERYTHING. But it's pretty darn awesome. This is what I've done with it:

1) Employee Performance Management Solution (50 tables, probably several thousand lines of custom code added)
2) Industrial Skills Testing Solution (probably several hundred lines of custom code added)
3) Survey - Employee Engagement, Climate Survey, and 360 Feedback Solution (probably several hundred lines of custom code added)

It's all cloud based. The first and 3rd solutions utilize the built in charting capabilities, and I also figured out how to use the Google chart API to do organizational charts. That type is not in PHPRunner, although pie, bar, gauges, etc. are in it. This tool is from XLineSoft.

Just my 2 cents. I am probably in the 6 figures now in total revenue generated from these solutions. So they must be pretty decent, right? And in many cases, led to other organizational development consulting work. I am not an IT consultant, I am a leadership and organizational development & business consultant.

Chuck
Go to the top of the page
 
AlbertKallal
post Jun 11 2020, 10:21 PM
Post#32


UtterAccess VIP
Posts: 3,101
Joined: 12-April 07
From: Edmonton, Alberta Canada


@Frank

I don't think that the office + desktop is dead anytime soon. But I will agree that the winds of change are occurring.
So, desktop and especially the "huge" investment in say Outlook in the business world?
I doubt that will change soon.

but, where the new work and opportunism are right now? Well, just like there was "tons" of work and opportunity in Access say 15 or 20 years ago?
(even lots of job boards were looking for Access developers. I use to cruise them all the time - just to see who and what companies in town and about were looking for Access developers). Now, those same job boards RARE have Access developer postings.

But for web work? There is a lot of work to be had. Even for business of a size that would spend money on Access types of applications. It just now that such applications are well into maturity, and they work well. So, not a ton of work remains.

@Chuck:
I can only state that there is a LOT of opportunity for work in web land.

@Everyone.
For the last 20 years of the desktop computer boom? Well, it still going strong, but the applications and software that companies use "internal" has very much matured. However what has occurred is that all that data and software is "locked up" internal. But, now with some type of web portal, then in place of a sales rep pulling up the software, creating or checking status of a quote? And THEN sending it off to a customer? Well, with a web portal, the customer can pull up that information and enter information about a request for a quote or what ever. I mean when is the last time you phoned up FedEx for package tracking? (we used to do this - and the person on the other end would fire up some INTERNAL software and read from that screen to you!).

Same goes for booking a trip or holiday. They would fire up some internal software, and then READ it to you on the other end of the phone.

So, there is truckloads of information and data and software that is "internal" facing in just about every company. But parts of that data, and parts of that information can be used and interacted with by customers. Why have a customer email a sales rep about a quote or status of a project when they can simply log on, and look up that information on their own?

So, customer self serve "portals" is really where the hot market is right now. The reason is that if you look at internal software systems and processes? Well, at some point they usually result in some kind of interaction with the customer. And at those inflection points, that is a opportunity for the customer to use parts of that software.

So, just like you can walk into your bank to do banking? They will likly fire up some 20 or 30 year old software on some green screen system.
But, you can also go home, fire up a the web, and get your account balance and pay bills - just like you used to at the bank. So, they don't expose ALL OF that internal software, but ANY part that interacts with a customer, or when staff is talking to a customer and using say YOUR great software? That is a opportunity for some kind of web based interaction. And companies pay $$ for that, because every web based interaction is done without chewing up employee time.

So, just like Access had tons of opportunity in the past? Right now, looking at ANY of my past customers? There are some types of interaction that could be moved out of the internal software, and exposed to customers via the web. And as noted, companies happy pay for these kinds of systems, since they easy realize that each interaction by the web is costing them no employee time. Updating some older payroll software to some better version or new accounting software does not really save the company money or much time. However, allowing say employees to "log on" and check their holiday pay, or when they will take holidays, or have customers look up project status, or even start a new project or process? All that can be done 24x7, and done without employees interaction with that truckload of software they developed over the last 20 years.

So a huge ready made market exists right now. And that market is looking at all the software written for internal use, and looking at what parts and what business processes can be moved out to the web. To me, that's were near all the work is occurring right now, and where most will continue to exist.

And as one gets better and better with web tools?
And as web tools get better and better?
Then the case for building web software in place of desktop software is growing by the day.

The desktop is not dead. And it seems oh about every 5-6 years we have some big discussion - say here on UA!

But, this trend is real, and the march away from the desktop is real. And it not so much the desktop is going away, but those systems (internal) are well made, been worked on for years, and they tend to work well, and not need a lot of love and care anymore. But those same companies are still very Hungary for web solutions that enable customers to get at all that wonder data and wonder software that been built up over the last 20 years.

I thus suggest that one does consider learning and adopting some form of web skills.
I also have opportunities for Android, and I am now quite comfortable writing Android software. (but, I used a very VB like system (B4A - Basic for Android).

The desktop is not dead, nor are internal systems. But as noted, the work to be had is lower since those systems are already built, and what business does not run some major software to run things these days? (they all have that software). But, what they don't have is that software for working with customers - so that's where the money is going right now. The desktop "value" and "investment" still exists, but it not pulling in dollars because it does not have to! (it already works well).

So, to me, the web is just a question of opening doors since desktop software is already running and working well for most business.

My first web software was Actually access web applications. And while Access Web was really limited? I learned some VERY valuable things. Most critical was I walked away with a great grasp of browser side software (client side), and that of grasping server side code. And amazing enough? Access web V1 allowed you to write client side browser code! My tic,tac,toe game I wrote with Access web? When you hit the clear button to start a new game? All that code ran client side without a round trip to the server!!! (how cool is that).

I don't know for everyone what system to adopt web wise right now. I do think that as my 5 minute example above shows? asp.net + vb.net is really nice, really easy, and gets you up and running rather fast. But, to make great looking web software? It was too much work to get all the bits and parts finally together that allowed me to become productive. I mean, what good is some buttons if the result looks like [censored]? (and this is again where Access web V1 nailed it!!! - what you created looked VERY nice).

Anyway:
All I can say is?
If you still very active as a access developer? Then great, but if you looking anything longer term then 5 years? You HAVE to start offing web skills as part of your offerings - it just a must have skill and every year this will become double so. It is where all the work and opportunities for Access "type" of developers is occurring.

So, just like some Access developers stumbled into Access, and all of a sudden they are writing Access software?

Well, look at @Chuck's example above? He stumbled into some web jungle and is now producing web software. Just like Access opened so many doors for so many people to enter this IT industry?

Well, Access + web skills in many ways is BETTER then just web skills, since all that business work in Access can now be parlayed into web systems - often with existing companies that have access or access like "internal" systems. The trick now is to find and see what parts can be moved to the web. (the internal core of such systems can and should remain as internal).

Just like Access on its own is not a free ride and ticket (like it was years ago). Well, now every Access application I work with is SQL server for the back end. And that now is just a stepping stone to web enabling parts of that software.

Sorry for the long post!!!
Last but not least?
Access is still a killer development tool for internal software systems. And being able to offer web parts and web portals that work with that internal software is where all the action and work is occurring right now..
R
Albert
Go to the top of the page
 
bobalston
post Jun 11 2020, 10:57 PM
Post#33



Posts: 107
Joined: 12-October 04
From: Dallas area


I think it would be very interesting to know if any Access MVPs have taken the plunge and tried out low-code web application development software and especially if they found any they liked and now use when the occasion arises.

Bob
Go to the top of the page
 
FrankRuperto
post Jun 12 2020, 10:44 AM
Post#34



Posts: 1,099
Joined: 21-September 14
From: Tampa, Florida USA


I feel like we're leaving the end-users out of the equation. What makes life easier for a developer may not necessarily be what's best for the customer. It sure would be nice to transition from desktop Access development to a new web development tool that's similar, but that should not be the only factor to consider.

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
DanielPineault
post Jun 21 2020, 03:30 PM
Post#35


UtterAccess VIP
Posts: 7,383
Joined: 30-June 11



Do remember they have tried to bring Access to the Web 3 times now, and failed in all instances.

If you want web, true web, then you need to use web technologies: MySQL/PHP, .net, ...

The middle ground is a hybrid Access front-end using an Azure back-end. But for this to work properly, the front-end does need to be built properly and not use typical Access design (pull everything).

--------------------
Daniel Pineault (2010-2020 Microsoft MVP, UA VIP, EE Distinguished Expert 2018)
Professional Help: https://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: https://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
AlbertKallal
post Jun 22 2020, 10:05 AM
Post#36


UtterAccess VIP
Posts: 3,101
Joined: 12-April 07
From: Edmonton, Alberta Canada


QUOTE
.NET has a visual designer but .NET applications are also extremely bloated.


Really? I have used every platform and development tool in the last 30 years. I find the .net system one of the most efficient and light weight platforms.

StackOverflow at one time ran on a single 4 core server - it built with .net. All of your code is compiled, and eventfully runs as native - very fast, very tight.

Remember the access "test" browse tables example.

This one:



That WHOLE program is 26k!!!!

(compiled). Now I would have been happy with 100k in size (so 12 could fit on a single 1.2 sized floppy disk). But 26k for all that function and ability? A "icon" on this web page is larger!!!

And during web development, you can single step your code (same keys as access VBA for debugging - short learning curve). And Visual Studio installs a light weight version of the the web server. So when in code? Well, you just hit F5 like in Access VBA, and the code runs in the web browser. This tight integration and debugging of your web code is a gift horse. This allows ease of development, but also saves you from having to setup or have a web server.

Not the end of the world here - but the .net environment is the most tight and low code environment I can think of. And the rest of the industry is only now catching up in terms of performance. The other tools in this industry are HEAVY a based on scripting languages, and that means source code is placed on the server, and such files are far larger (and more vulnerable) then a compiled .dll that you get with .net web development. It only been the last few years that web servers are now smart enough to compile these scripting systems into native Intel code. The .net system not only runs as native, but the resulting code you write is beyond small and efficient. I have never used anything close that can produce the above open Access and browse files - all in a final compiled package of 26k.

Some of the .net frameworks are rather large. But from a developers point of view? It is a VERY light weight system, and as noted the above whole screen shot of the above .net sample application to open Access and browse access tables? it was 26k in size after compiling. Beyond remarkable - and beyond light weight.

Not really a big deal, but I thought I should point out that when it comes to project size, less code and smaller and tighter project sizes, even for web projects? You find the .net web projects smaller then just about anything else.

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada
Go to the top of the page
 
FrankRuperto
post Jun 23 2020, 09:03 PM
Post#37



Posts: 1,099
Joined: 21-September 14
From: Tampa, Florida USA


QUOTE (AlbertKallal)
However, to do a really great job, then quite a bit of work is required with asp.net. But it is quite easy to start building some easy forms.

But, it still a pain to pull and write data to and from tables. I have written a few "small" helper routines in asp.net, so now I can quite much drop a bunch of controls on a web page, call one routine to fill out the controls, and another routine to "save" the controls data back to the table. So as I go down this road, I am writing less and less code and moving closer and closer to a access like experience when I do web development.

You just said it yourself. Most Access apps we work with are great, but complex, requiring "quite a bit of work with asp.net". I am not saying bloated in the sense of how much space is consumed by a compiled .net program, rather how many lines of code .net developers have to write to achieve equivalent complex Access functionality.

I honestly feel a web development library of VBA-like functions and a 4GL web syntax language can be created that would be similar to Access VBA, but we must remember that the web world is stateless. There's very limited interactions that can be done with a local filesystem, like we do with e.g. Office Automation.
This post has been edited by FrankRuperto: Jun 23 2020, 09:16 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
2 Pages V < 1 2


Custom Search


RSSSearch   Top   Lo-Fi    9th July 2020 - 12:05 AM