MS Access per chi lo conosce davvero (e non per chi ci fa giochini), è un rapidissimo, e a suo modo potente ambiente di sviluppo che ha più o meno tutto quello che occorre per progetti gestionali.
Chi ne parla male semplicemente non lo conosce.

Questo articolo è per persone che sviluppano separando front-end e back-end, che sviluppano oltre una certa concorrenza di utenti con un database server dall'altra parte, che creano file accde rinominati in accdr, che non agganciano componenti 'strani' legandosi ad altri software rendendolo intrasportabile o quasi, che usano l'integrità referenziale nei DB, che usano gli ODBC per restare liberi nella scelta del DB.
Insomma chi lo usa in 'produzione' su aziende sapendo come si fa.

La premessa è che uso Access da sempre con DB accdb ma soprattutto su SQL Server Express o su MYSQL (in un caso anche PostgreSql).
Molti erano ex programmi con accdb girati su DB SQL perchè cresciuti nel tempo.
Tutto funziona perfettamente da decenni.

In decenni di utilizzo da parte degli utenti di decine di programmi (anche con centinaia di tabelle) in integrità referenziale unici problemi:
Corruzione di DB accdb per una rete che cascava spesso e tanti posti di lavoro (risolti passando il DB a SQL Server Express).
Problemi di prestazioni quando passavi i 5 o 6 utenti con DB abbastanza corposi (risolti passando il DB a SQL Server Express).
Un cliente che corrompeva il DB tutti i giorni (colpa di una scheda di rete Realtek difettosa, mi ha fatto impazzire), risolti cambiandola.
Stramaledetto aggiornamento recente di Windows che ho dovuto far disabilitare, che ha dato problemi a 'update inner join'.
Una volta risolti mai più problemi.

Distribuire un applicazione fatta con MSAccess richiede attenzioni.
Di solito non è un problema se il cliente non ha Office.
Gli si passa in Runtime per la versione di Access in uso e non ci sono costi.
La versione Express (gratuita) di SQL Server di solito è più che adeguata per il clienti (4 GB di DB è un limite alto).

Se il cliente ha Office se il programma è a 32 bit non può girare su uno a 64 viceversa.
Si può scrivere un programma che funzioni a 32 e 64 ma deve essere compilato (accde), su due Windows diversi e con due Access diversi (e relativi costi).
Guai mescolare le versioni italiane con quelle inglesi o altro, si genera caos da cui è difficile uscirne.

Qui cerco di fare il punto della situazione e lo aggiornerò con gli input dei vari sviluppatori che mi arriveranno di volta in volta.
Fino alla versione 2010 non ci sono particolari problemi.

Scegliere la versione di sviluppo è condizionante per gli anni a venire, per cui non va fatto 'alla leggera', perchè gli effetti sono differiti nel tempo e quasi irreversibili.
Ancora stramaledico quando ho scritto un po di codice adp (non più supportato), riportato ad accdb non senza sofferenze (penso di essere uno dei pochi in grado di fare questa conversione pesante).
Oggi uso la versione 2021 a 64 bit dopo aver usato per anni la versione 2010 32/64.

Il passaggio a 64 bit dà problemi su chiamate di routines esterne (in alcuni casi davvero pesanti spesso da riscrivere), ma molti non le hanno mai fatte, per il resto è indolore.

Qui si trova un ottimo specchietto con le versioni di Access e relativi presequisiti e funzionalità, come vedete c'è tanta roba, positivo che la versione 2019 ha cose molto interessanti
http://fmsinc.com/MicrosoftAccess/history/features.htm
Di negativo che la 2019 di Access obbliga a Windows10, obbligo che non esiste per la 2016 che va anche su Windows7 (ma oggi molti sono oramai su Win10 se non Win11).

Microsoft sta facendo di tutto per 'caldeggiare' un abbonamento 'perpetuo' (che trovi in Office365).
Ma sembra ci siano incompatibilità non da poco tra il mondo delle versioni 'stand alone' e quello delle versioni in abbonamento.
Ovviamente io devo poter sviluppare sia per chi ha già 365, sia per chi rimane con le versioni Stand Alone.
Comunque l'uscita della versione non in abbonamento di Access la 2021 ha fatto sì che finalmente aggiornassi il software.

https://support.office.com/it-it/article/installare-e-usare-pi%C3%B9-versioni-di-office-nello-stesso-pc-6ebb44ce-18a3-43f9-a187-b78c513788bf
"Se si ha un abbonamento a Office 365 o una versione non soggetta ad abbonamento, ad esempio Office Home and Business 2019, 2016 o 2013, nella maggior parte dei casi non è possibile eseguire queste versioni insieme nello stesso computer."

Al di là di questa considerazione Access 2007 /2010 / 2013 / 2019 /2021 sono riuscito di norma a farle coesistere tranquillamente (nel caso vanno installati a rovescia), unica sfiga in alcuni casi attendere lo scambio delle librerie (insopportabile).
Dirò di più se non si usano le caratteristiche di Access 2013 il programma di 2010 l'ho sviluppato tranquillamente su entrambi gli Access per poi creare l'accde da 2010.
Tenete conto che il 2010 è stata l'utima versione con il 'wizard' che genera il setup.

ACCESS 2019 (di cui non esiste Runtime) o ACCESS 2016?
Attenzione ACCESS 2019 supporta solo Windows 10 (non Windows 7).

Se ti muovi con il 365, non usi la versione stand-alone (che la paghi una tantum).
Se ad esempio hai installato 15 PC tutti con la versione 'stand alone' che siano 2 o 15 non fa differenza.
Con la versione 365 devi sempre ricordarti chi abilitare o disabilitare, altrimenti continui a pagare anche se non la usi, e sei costretto ad essere sempre aggiornato.

https://support.office.com/it-it/article/distribuire-un-applicazione-di-access-7bb4f2ba-30ee-458c-a673-102dc34bf14f
"Scaricare e installare Access Runtime per Office 365
Nota    Questo runtime di Access si applica anche a Access 2019."

Attenzione, il runtime è oggi quello del 365 anche per chi sviluppa con Access 2021.
In realtà la cosa funziona perfettamente per le macchine Win10, per le macchine Windows7 delle volte si è costretti a ripiegare verso il precedente Access runtime, che per ora nei miei programmi non ha dato problemi.

Se fate le chiamate nel codice in versione 32/64 lo stesso programma lo fate girare tranquillamente nei due ambienti.
Ricondo che se il runtime del vostro programma è a 64 bit se c'è l'Office DEVE essere a 64 bit, e viceversa se è a 32, se Office non c'è non ci sono problemi.
Il problema è che anche lo stesso sorgente se volete compilarlo per 32 o 64 dovete allestirvi due macchine (magari virtuali) e comprarvi due Windows e due Access.
Questa è davvero una scocciatura.
In realtà in una macchina lavoro per i sorgenti a 32 nell'altra per quelli a 64, quando passo a 64 lo faccio perchè tutti i miei clienti abbandonano la versione a 32.

Insomma per i 64 bit ora sviluppo con Access2021 ed eseguo il programma con il Runtime 64 di Office365.
L'importante è non creare un wizard di installazione msi (sono incompatibili), ma questo dovrebbe rendere solo scomoda l'installazione.
In realtà ho letto (non sperimentato) di problemi su questo fronte.
Per cui installare con un Setup oggi dovrebbe essere un casino (c'era un programma alternativo ma non sembra più esserci).
Rassegnamoci ad una installazione manuale o uno dei tanti programmi non Microsoft per preparare ODBC registri, copiare i files, creare le icone le voci di menu ecc.

Spero quanto prima che Microsoft crei un Setup Wizard come c'era nella versione 2010.
Mi piacerebbe da Access 64 poter compilare la versione 32 (anche se so che nel tempo questo problema andrà sparendo).

ATTENZIONE!! durante l'uso ho scoperto un grosso problema che non sono riuscito ad aggirare!
Il problema si è verificato usando Access 2010 e Office 365 runtime 32 bit, collegato via ODBC a MYSQL.
Usando una tabella linkata in cui è presente un campo Decimal (8,3) durante un insert nel campo di un recordset, Office Runtime va in crash.
Con altri campi decimal questo non si verifica.
Dopo la segnalazione a Microsoft ho ottenuto risposta e la cosa dovrebbe risolversi
https://www.devhut.net/2020/06/08/access-version-2005-build-no-12827-20268-causing-problems/

Il problema si è risolto nella versione 2021.
Per chi usa MYSQL ATTENZIONE AL CHARSET del DB (uso Latin1 Latin1_swedish_hi), altrimenti potete ritrovarvi problemi devastanti nei campi chiave con gli accenti.

ADO o DAO?

Legandomi a ODBC opero di solito con DAO anche se è considerato piuttosto vestusto, ma non ha dato particolari problemi.

Attaccarsi al di fuori di SQL Server?
Collegandomi via ODBC a MYSQL al posto di SQL SERVER non ho avuto particolari problemi.
In determinate situazioni prima di fare un UPDATE devo annullare il contenuto del campo in modo da non generare situazioni di Interlock.
Comunque il sistema funziona, ho DB attaccatti contemporaneamente a tabelle su MYSQL, SQL Server, Access ecc.

Strumenti per manipolare i DB.
Mi permetto di consigliare senza dubbio l'Open Source DBEAVER.

Access 2021.
Dopo parecchio tempo finalmente torna a comparire una versione Stand Alone di Office.
Purtroppo non ricompare il Deployment Wizard di Office 2010.
Continuo ad operare con DAO senza alcun problema.
I vantaggi del nuovo Access non sono così evidenti, spero finalmente rimettano mano alla gestione della grafica che sia vista come una funzione integrata e non come un accrocchio.
Una gestione che permetta di creare menu in modo facile come con le macro sarebbe oltremodo auspicabile.

PERIODICAMENTE QUESTO DOCUMENTO VIENE RIVISTO OGNI CONTRIBUTO E'BENE ACCETTO