Cerca nel sito

Sviluppare in MS Access per distribuire applicazioni gestionali

20. 02. 05
Visite: 91

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.

HO DECISO DI PASSARE A 64 BIT E CAMBIARE VERSIONE DALLA 2010
QUI AGGIORNATO LO STATO DELLE MIE PROVE
CHI VUOLE CONTRIBUIRE CON TEST E SUGGERIMENTI MI AIUTI, LI INTEGRERO'

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

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.

Sulla carta in realtà il runtime di Office 365 dovrebbe funzionare anche con Access2019.

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

Insomma se sviluppo con Access2019 dovrei poter eseguire il programma con il Runtime 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.

Sto per fare esperimenti con Access 2019 e Office 365 Access Runtime (nella speranza che prima o poi esca Access 2019 runtime).
Quello che al momento devo capire quanto la versione Access 2019 va in conflitto con la 365 (sempre che compaiano problemi di questo tipo).