La premessa é che sui forum si è generata una vivace (e sperata) discussione, ne consegue che questo documento è stato affinato (lo stesso titolo era volutamente 'polemico', oggi riportato ad una struttura più sobria).

Qualche chiarimento.
Il documento parla di Access usato come Front-End nell'uso con i Database Server via ODBC, l'uso con un solo file condiviso in multiutenza non è più consigliabile, con più di due utenti assolutamente deprecabile.
Non è neanche un modo per dire che non esistono oggi strumenti nuovi in grado di lavorare meglio.
Progetti stabili aggiornabili non vanno rifatti (a meno che non siano molto piccoli), ma manutenuti con attenzione.
Meglio un programma stabile e consolidato fatto con uno strumento di qualche anno fa, rispetto ad uno mal stutturato sviluppato con strumenti recenti.

Tante volte sento criticare MS Access, ma sempre da chi non lo conosce realmente, ma penso che vadano criticate le soluzioni sviluppate più che gli strumenti usati.
La principale critica che mi sento di fare al momento è che esiste solo la versione per Windows ed hanno tolto il setup wizard, che come spiegherò è comunque oggi un problema relativo, e che manca un runtime Linux.

Prima di tutto occorre capire perché uno dovrebbe continuare ad usare MS Access.
Può essere usato per manipolare basi dati, con lo stupendo vantaggio di poter usare un'unica interfaccia per DB diversi.
Ad esempio collegare via ODBC un DB Mysql, uno SQL Server ecc.ecc. e usare delle query che lavorino indifferentemente e congiuntamente su entrambi.
Per fare questo fortunatamente esistono altri strumenti cross platform ed Open Source come ad esempio DBeaver, meno amichevoli ma più potenti.
Quindi non è questo il vero aspetto importante.

Ripeto NON si parla di Access come programma che lavora con un DB su un file condiviso (che può andar bene solo per programmi in monoutenza o quasi).
Si parla di Access che lavora collegato via ODBC ad un Database Server, MYSQL, SQL Server ecc.

Parlo di Access per la sua potenzialità di scrivere programmi completi (non usando le macro se non per i menu o poco più) in VBA.
Ricordo che per farli girare si usa il runtime (gratuito).
Chi lo usa per sviluppare non lo usa come 'monolito' anche se dentro MSAccess potete mettere tabelle, query, report e codice.
Chi lo usa professionalmente non mette MAI il DB mescolato al programma (altrimenti aggiornando il programma aggiorni anche il DB dei dati).
Non c'è praticamente mai l'esigenza di ricorrere a librerie esterne.
Programmi query e tutto il resto stanno su un DB (dove di fatto sta il 'sorgente'), i dati di solito stanno su DB esterni che si potrebbero collegare direttamente.
Ma per mantenere una intercambiabilità da un DB all'altro conviene collegarli via ODBC.

Ed ecco che ho programmi che mi consentono di selezionare durante l'accesso se lavorare in produzione o test, e che magari lavorano su DB di tipo differente.
Ne ho uno che aggancia dati su SQL Server, MYSQL, ed addirittura un DB remoto MYSQL su un server Web esterno.
E tutto questo da una interfaccia unica.

I form te li disegni/copi così come tutti gli oggetti che ti servono, idem i report e le query.
La premessa è che per fare cose di questo tipo occorrevano spesso tools e librerie diverse da far coesistere anche in caso di aggiornamenti.
Nel caso di Access avevi praticamente tutto per sviluppare un gestionale completo.
Non è un programma compilato? E chi se ne frega, in un gestionale l'ultimo problema è la velocità dell'interfaccia, quello che conta è la velocità del DB.
Il debugging è facilissimo, in caso di errore se hai il sorgente va sulla riga di codice, puoi ispezionare o cambiare valore alle variabili avanzare step by step o saltare da un punto all'altro ecc.
Questo si traduce in assistenza sugli errori rapidissima.

Il difficile degli strumenti 'RAD' per la programmazione veloce, è dare il giusto mix di tutto quanto occorre normalmente per scrivere codice pulito, chiaro e sintetico e fare quello che occorre velocemente.
Non avessi avuto uno strumento del genere difficilmente avrei potuto da solo gestire progetti con centinaia di form video e tabelle (un ottantina di progetti a partire dalla versione 1.0).
Siete in grado di produrre un risultato ad altissima affidabilità (l'importante è gestire sul DB, possibilmente su un Database Server, l'integrità referenziale).
A oggi ogni qual volta trovano un bug (campo troppo lungo troncato o altro), normalmente trovo l'errore in un paio di minuti.
Se devo scrivere un programma di gestione magazzino completo sono in grado di farlo in tre giorni.

I programmi più vecchi miei ancora attivi sempre aggiornati risalgono al 1992 e non hanno mai dato problemi di affidabilità pur lavorando 8 ore al giorno.
Ho programmi che operano ininterrottamente anche su 15 posti di lavoro.
Se apro il sorgente più vecchio è scritto chiaramente, con pochi orpelli e sono in grado di capirlo/correggerlo anche ad anni di distanza o se ci hanno messo mano altri.
Se vi guardate in giro e ignorate software banali fatti da incapaci, troverete montagne di programmi anche enormi sviluppati in MS Access affidabilissimi.

Oggi tutti spingono la programmazione Web, pure io uso il PHP per fare qualche interfaccia esterna che non richieda installazione (carico ordini o altro), ma su piccole funzioni specifiche.
La programmazione Web non è adatta alla parte gestionale, gli strumenti sono disgregati tra librerie diverse, richiedono tante ore uomo per essere portati avanti.
La parte grafica anche con la massima cautela 'imbratta' il codice.
Le tecnologie usate Javascript o altro fanno coesistere tanti strumenti diversi, ad ogni aggiornamento il rischio aumenta.
Il debugging di conseguenza è davvero scomodo.
Per non parlare della varietà di Browser e le loro particolarità, per cui spesso e volentieri troviamo problemi inaspettati in particolari situazioni o a fronte di aggiornamenti.
Insomma giusto usare determinati linguaggi in determinate situazioni, usarle per un gestionale aziendale lo trovo poco produttivo, lento, scomodo, uno spreco di risorse.
Certamente sono concepiti per uno sviluppo cooperativo.
In un gestionale per multinazionali o per chi ha strutture con numero elevato di accessi (shop on line), che necessitano di bilanciamento del carico, in quel caso lo sviluppo web è quasi imprescindibile, ma non può che essere gestito da un team.
Ma in un gestionale aziendale quando al massimo hai una decina di posti di lavoro, lo sviluppo stand alone è un vantaggio come sicurezza, monoliticità stabilità, controllo.
Certamente Access non è adatto ad uno sviluppo cooperativo, se fatto occorre una buona organizzazione interna (ovviamente valida se gli sviluppatori sono al massimo 3).
Vuoi dare accesso dall'esterno, oggi ci sono le VPN, le macchine Virtuali ecc.
I miei programmi all'occorrenza girano sui sistemi touch magari Android che semplicemente lanciati da Linux o da un vecchio XP, aprono un RDP su una macchina virtuale Win10.
Ecco che un form Access lavora perfettamente anche su un sistema Touch (anche se ovviamente è un aggiramento di limiti).
Potete sempre mettere una macchina virtuale sul cloud collegata alla rete accessibile in RDP/VNC.
Insomma quelli che erano limiti invalicabili oggi si superano facilmente.

Il codice è stabile, monolitico, debuggabile.
Poi per carità mi è capitato di fare calcoli sullo storico sul database server perché via ODBC quel tipo di calcolo impiegava 6 ore nell'altro caso 5 minuti.
Ma situazioni del genere mi sono capitate tre volte in 30 anni.
Dal 1995 a oggi ho fatto praticamente di tutto su su tutto, ho le routines per fare il 99% delle cose che mi occorrono e su Internet in VBA si trova praticamente tutto.
C'è una comunità di sviluppatori florida ed attiva per cui il supporto vicendevole è garantito.

Ora i miei programmi ancora 'attivi' girano tutti a 64 bit, caso di aggiornamento distribuiscono automaticamente la nuova versione a tutti.
Poi è chiaro che se uno non sa usare uno strumento per come deve essere usato, fa tutto con le macro, usa reference che lo attaccano a librerie aggiuntive creando dipendenze, non struttura il codice non usa le funzioni ecc. ecc. produce porcheria, su qualsiasi linguaggio.

Attenzione anche la Microsoft ha le sue colpe, per un vecchio sistema di sviluppo ha fatto saltare la licenza e pur in possesso della confezione originale ho dovuto cercarne uno nuovo introvabile da ricomprare.
Quando hanno spronato gli sviluppatori a fare programmi adp (un casino), poi è tornata sui suoi passi mandandolo in pensione e lasciandoti nei casini (riportarli ad accdb è stato disastroso).
Per non parlare di quando tutti gli ODBC a seguito di un aggiornamento hanno mandato in blocco tutti i clients, per poi capire che il problema si risolveva usando altri ODBC.

Non posso certo testare ogni giorno altri sistemi RAD in giro per la rete, sono strumenti che richiedono studio approfondito.
Per anni per raggiungere livelli di produttività così elevati in sicurezza non avevo trovato nulla di analogo, c'erano programmi spesso costosi, ma non puoi riprovare tutti gli strumentii, continuamente.
E' raro avere ambienti di sviluppo così longevi.

Ma ovviamente i tempi cambiano, così anche le tecnologie, ho quindi deciso di scrivere un documento provocatorio per vedere cosa sarebbe uscito fuori.
Ed ecco che questo documento girato sui forum mi ha aiutato molto a capire che strumenti possono soppiantare il datato Access, senza parlare delle nuove funzionalità che i nuovi strumenti forniscono.

Oggi direi i tempi sono maturi, lo stesso approccio può essere poco costoso se non gratuito, esistono delle Community versions che possono aiutare.
Alla fine ho trovato finalmente due potenziali alternative C# ed Entity Framework, Delphi e FireMonkey e il corrispondente Lazarous Open Source.
Dopo un po di tutorial, qualche consiglio, ho deciso di approfondire la prima accoppiata.
Qualcuno potrà obbiettare che potevo guardarci prima, l'avevo fatto alcuni anni fa ma i risultati non erano quelli di oggi, oppure era troppo costoso sperimentare.
Oppure semplicemente non cerchi una alternativa se non ne senti l'esigenza.

E per il software già sviluppato ... lunga vita a MS Access