Cerca nel sito

Sviluppare in MS Access per distribuire applicazioni gestionali

20. 02. 05
Visite: 255

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.
Oggi uso ancora la versione 2010 e sviluppo a 32 bit e a 64 bit.

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 per molti miei clienti è fattibile).

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.

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 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), un problema non da poco.

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."

Ho notato che con questo Runtime a 32 bit faccio girare tranquillamente anche i programmi fatti in Access 2010.
Se correggo il codice on le chiamate a 64 bit lo faccio girare tranquillamente con il runtime a 64.
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 Access2019 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).

SE SAPETE QUALCOSA IN PIU' FATEMELO SAPERE