Newsgroup: it.comp.appl.access
Titolo: Access versus Visual Basic. Chiedo aiuto per prendere una decisione importante.

Chiedo aiuto agli esperti. Ho provato a cercare nel Sito Comune ma non
ho trovato un approfondimento sull'argomento.
Si tratta di questo: una grande azienda di Torino possiede un
centinaio di negozi (grandi magazzini) dislocati in tutt'Italia. Ogni
negozio ha due o tre registratori di cassa. 
Questi registratori sono composti da una apparecchiatura IBM (che è
praticamente un Personal Computer), corredato da un monitor a colori
14 " di tipo  touch screen,  tastiera, mouse, dispositivo per la
lettura del barcode, fessura di scorrimento incorporata nella tastiera
per la lettura di badge, più un piccolo display rivolto verso il
cliente, affinchè questi possa leggervi il prezzo dei vari articoli,
collegato tramite porta seriale, più una stampantina per l'ottenimento
dello scontrino fiscale,  anch'essa collegata ad altra porta seriale.
Sistema operativo Windows XP per le casse nuove, Windows meno recenti
per le vecchie casse che verranno man mano sostituite.
Le due o tre casse del negozio, sotto l'aspetto dell'operatività, sono
indipendenti. Ogni cassa possiede il software e i dati necessari per
lavorare in modo autonomo.
Il software è costituito essenzialmente da un programma di gestione
della vendita, più vari altri programmi che consentono le
comunicazioni tra il negozio e la Sede, e altri programmi di utilità.
- I programmi sono stati realizzati, a suo tempo, in Clipper / DBase
III dal personale stesso del Centro Elaborazione Dati dell'Azienda.
Il programma di GESTIONE DELLA VENDITA presenta sul monitor, rivolto
verso il cassiere,  le transazioni di vendita man mano che il lettore
laser legge i bar-code sulla confezione dei prodotti, ne mostra il
prezzo tramite accesso ad un data base caricato sulla cassa stessa da
cui trae anche sconti e condizioni di vendita speciali, ecc.  -
Consente la gestione di eventuali resi e di particolari movimenti ed
eccezioni. - Pilota anche per ogni transazione il piccolo display lato
cliente mostrandone il prezzo e a fine vendita stampa lo scontrino
fiscale, oltre a registrare nel data-base le transazioni di vendita
effettuate.
La gestione del display lato cliente e della stampatina fiscale
avviene inviando gli opportuni comandi alle due porte seriali. Ecco
perchè in un mio precedente post (Gestione porte seriali tramite VBA)
chiedevo se ciò fosse possibile in Access. Mi ha risposto cortesemente
Lorenzo.
I programmi di COMUNICAZIONE CON LA SEDE, che ha come computer
gestionale un AS/400, ricevono nottetempo le modifiche ai data-base
degli articoli e dei relativi prezzi e sconti, e trasmettono alla sede
le vendite del giorno precedente.
Vari altri programmi di UTILITA' consentono diverse funzioni
complementari.
Come detto sopra tutti i programmi sono stati realizzati a suo tempo
in Clipper/DBase III e DOS e funzionano egregiamente, anche se con
interfacce piuttosto spartane.
Si è deciso di riscriverli per varie ragioni: per fornire una
interfaccia più elegante (e più efficiente), potendo sfruttare anche
il touch-screen del monitor, utilizzando un linguaggio più moderno e
più conosciuto nell'ambiente informatico, per eventuali future
manutenzioni da parte di terzi, ma anche perchè si temeva (e si teme)
che con nuovi registratori di cassa e con nuovi sistemi operativi il
Clipper, il DBase III e il Dos possano non essere più supportati
compiutamente in futuro.
In qualità di consulente di questa azienda, per rendermi conto della
complessità dell'ambiente, e poichè conosco discretamente bene Access
(e non conosco Visual Basic, né Delphi, né altri linguaggi) ho
iniziato a convertire l'applicazione in Access, partendo dal programma
di Gestione della Vendita che è il più complesso. In effetti non è un
programma banale, ma in Access non presenta particolari difficoltà.
Ma, mentre procedevo nella sua realizzazione, ho cominciato ad avere
dei dubbi, corroborati anche dal parere di alcuni colleghi.
1. LICENZE - Un programma .mdb richiede che su tutte le casse (circa
250)  debba  essere installato Office/Access. Ciò comporta anzitutto
un problema di costo delle licenze. Se una licenza costa circa 220
euro, per 250 casse si ottiene un totale di 55.000 euro. Soldi che
realizzando il programma tramite un altro tool in grado di ottenere un
.exe sarebbero risparmiati.
2. STABILITA' -  Ho la sensazione che un programma Access, anche
perchè dipende da una sovrastruttura Office, sia meno stabile e meno
affidabile, specie quando, con il passar del tempo, le 250 casse
cominceranno a differenziarsi come versione sia di Office che di
sistema operativo Windows, cosa che sicuramente si verificherà a causa
di rotture e guasti sia dell'hardware che del software, che
richiederanno il ripristino del sistema operativo Windows e di Office
nella versione più aggiornata.  Un .exe mi sembra non debba risentire
di questo.
3. COMPILAZIONE - Un programma .mdb è un programma interpretato in
fase di esecuzione. Anche questo fatto mi pare negativo rispetto ad un
programma compilato. - Inoltre un .exe è sicuramente inaccessibile
come codice all'utente. Un .mdb, anche se trasformato in .mde, mi dà
la sensazione che qualcuno delle 250 persone che dovranno usarlo,
possa in qualche modo manometterlo o guastarlo.
4. AMPIEZZA - Un programma compilato è più piccolo. Nel mio caso il
programma Access di Gestione della Vendita, una volta finito, mi
aspetto che sarà grande almeno da 5 a 7 MB. Quindi trasmettere le
nuove versioni a tutti i negozi richiederà più tempo (e minor
sicurezza di trasmissione sulle linee telefoniche), anche se una
versione .mde potrebbe essere più piccola, credo un 10-20% in meno.
5. DATA-BASE. - Questo non mi pare un problema, anche in una soluzione
Access. Infatti mi sono premurato, prima ancora di realizzare la parte
grafica e propriamente elaborativa del programma, di provare i tempi
di risposta nell'accesso al data-base. Questi devono essere molto
veloci, dato che la lettura del barcode dei prodotti avviene
consecutivamente, un prodotto dopo l'altro, a notevole velocità, e per
ogni lettura occorre accedere agli archivi dei prodotti e mandare a
monitor la risposta con prezzo e condizioni. Uno di questi archivi è
molto grande (circa 2.500.000 record). Ma ho constatato che, purchè
siano impostate correttamente le chiavi di ricerca dei record, i tempi
di risposta  sono del tutto soddisfacenti.
5.a - Scegliendo un altro tool di sviluppo al posto di Access si pone
anche  il problema di scegliere il data-base.  Però non vorrei cadere
dalla padella nella brace. Scegliendo un data-base tipo SQLServer mi
pare che avrei di nuovo problemi sia di licenza (per 250 casse circa)
che di complessità. Il data-base .mdb è molto più semplice da
installare e da trattare, rispetto ad un SQLServer, secondo me.
5.b - Scegliendo invece di conservare, come data-base, un .mdb,
risponde al vero che in questo caso, senza programma elaborativo
Access, non è richiesta la licenza? Mi dicono che un eventuale
programma, p. es. in Visual Basic, accederebbe all'.mdb tramite MDAC
(Microsoft Data Access Components - ODBC), e ciò non comporta licenza
Access.
Aggiungo che l'idea di voler convertire l'attuale pacchetto tramite
Access (e non tramite un altro tool di sviluppo) deriva anche dal
fatto che il Centro Elaborazione Dati dell'azienda attualmente è
autonomo nella manutenzione dell'attuale programma Clipper e vuole
continuare ad esserlo in futuro. I componenti del CED possiedono una
buona conoscenza di Access (oltre che di Clipper) ma non di altri
tools di sviluppo. 
Tuttavia, se lo sviluppo in Access si dimostrasse una soluzione non
valida, secondo me insistere su questa possibilità potrebbe essere
pericoloso per i problemi che ne deriverebbero in futuro. 
Se le Vostre considearzioni saranno negative nei confronti di Access,
suggerirò loro di utilizzare i 55.000 euro risparmiati dalla rinuncia
alle licenze Access per farsi aiutare a convertire l'attuale programma
tramite il tool scelto, e contemporaneamente di acquisire autonomia
nell'uso del medesimo sia con corsi che con manuali.
Mi scuso per la prolissità e Vi ringrazio.

 Mi scuso per la prolissità e Vi ringrazio.
Se hai problemi o dubbi continuare a chiedere
-- 
-- 
Massimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access

Mi scuso per la prolissità e Vi ringrazio.
Vincenzo Turturro
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------

Vincenzo Turturro
Non mi sono spiegato bene. Non conosco il tool di sviluppo Visual
Basic, ma il VBA lo uso a piene mani nel realizzare un programma
Access. Sono d'accordo con te che senza VBA non si fa un granchè.
Per il resto per ora grazie.
Leggerò con calma le tue osservazioni e poi mi farò risentire.
Ciao


-- 
Grazie per ora.
Leggerň con attenzione e mi informerň su quanto mi hai detto, poi mi
farň sicuramente risentire.
Ciao

-- 

Con Access da solo, senza conoscere VBA (che di fatto è una versione di Visual Basic), si va veramente poco lontano ...
Non mi ero spiegato bene. Su questo argomento ti ho già risposto.


 uno in gamba.
Quindi conoscerą bene la situazione e farą una buona analisi.
Se hai bisogno di ulteriori rassicurazioni (morali, quelle tecniche le 
continuiamo qui) puoi scrivermi in privato e ci mettiamo in contatto via 
Skype.
;-)



OK. Grazie. Digerisco piano piano tutte le informazioni che mi hai
dato e poi mi faccio risentire.
Però una cosa te la chiedo subito, se hai voglia e tempo: Non sono
ancora riuscito a capire il motivo reale, tecnico o di altra natura,
perchè tu (e altri) insistete nel consigliarmi l'uso di una base dati
di tipo SQL Server (o SQL Express) anzichè il database di Access.
Quali sicuri vantaggi offre l'SQL? E' più stabile? E' più performante?
Offre maggiori possibilità di accesso? E' più compatto?
Se non riesco a convincermi della convenienza di usare SQL, perchè
dovrei abbandonare il database di Access che finora non mi ha dato
alcun problema?
Saluti.




Con riferimento ai suggerimenti che con pazienza mi sono stati forniti
da  MA (Massimiliano Amendola) e da VT (Vincenzo Turturro), provo a
riepilogare quanto ho appreso, salvo ulteriori precisazioni da parte
di MA e VT  e della comunità:
1. Non è vero che sia necessario installare Office/Access su tutti i
computer che dovranno far girare l'applicazione Access, pagandone la
relativa licenza. Se si sviluppa il programma con appositi Developer
e/o Tools for Application si ottiene un programma run-time che può
essere caricato su qualunque computer (coerente come S.O.) anche in
assenza di Office/Access. In queste condizioni non è necessaria alcuna
licenza.
2. Ipotizzando che sui computer target sia installato Windows XP, la
soluzione migliore sembra quella di acquisire una  licenza per "Visual
Studio Tools for Application" tramite il quale si potrà ottenere il
run-time del programma Access da distribuire.
3. Sotto l'aspetto dell'affidabilità e della sicurezza Access non è
inferiore ad altri tools. Nella  versione .mde e/o runtime (di cui non
conosco ancora le caratteristiche) è inviolabile alla pari di altri
.exe.
4. Pertanto, vista anche l'alta produttività di Access e la relativa
facilità di apprendimento e di  utilizzo (che tuttavia non ne riducono
le caratteristiche di ...... e di potenza), il vostro consiglio è di
sviluppare la parte GUI  (Graphic User Interface - maschere, query,
report, codice, ecc.) tramite Access.
5. Per quanto concerne il database, invece, il consiglio è di
abbandonare Access/Jet a favore di un SQL Server. In particolare SQL
Server Express (che tra l'altro è free) potrebbe essere la soluzione
giusta. Express ha qualche limitazione (rispetto a SQL Server
completo), ma sempre meno del Jet di Access, e comunque limitazioni
ininfluenti in un ambiente di medie dimensioni.
---------------------------------------------------------------------------------------------
Vogliate ancora verificare la correttezza di quanto segue:
- L'SQL Express devo scaricarlo dal sito Microsoft alla voce: " SQL
Server 2005 Express Edition SP2" ? Annessa c'è anche della
documentazione? O dove la si può trovare? Ovvero, per utenti esperti
di Jet/Access ci sono molte differenze o ci si può arrivare per
deduzione?
- Serve anche "SQL Server Management Studio Express" che è indicato
nello stesso sito?
- "Visual Studio Tools for Application" per Access 2003 (S.O. Windows
XP) occorre acquistarlo presso un rivenditore di software? - Inoltre
saremo in grado noi come centro di sviluppo aziendale di utilizzarlo
oppure occorre un aiuto specialistico? Il C.E.D. è formato da
programmatori AS/400 esperti che si stanno formando anche in ambiente
Access. Come detto in precedenza c'è anche una ottima conoscenza
dell'ambiente DOS e Clipper/DBaseIII.
-------------------------------------------------------------------------------------------------
Ultime curiosità:
A seguito delle mie modestissime esperienze di Visual Basic / SQL
Server, non mi suonano nuove le "stored procedures" e i "trigger". 
Ma, in particolare, le incomprese "stored procedures" (con le loro
righe rosse, verdi, ecc., se non ricordo male) mi hanno sempre
spaventato. Non è mica che dovrò abbandonare le mie amate "queries" a
favore di esse? In particolare le "queries" sviluppate con tanta
facilità in Access in modalità grafica?
I "trigger" poi, che diavoleria sono? 
-----------------------------------------------------------------------------------------------------
Grazie e saluti a tutti 
Giorgio DANIELE - Torino




(.....)
I webcast su SQL Server Express a questo link (li trovi in fondo alla pagina):
http://www.microsoft.com/italy/msdn/risorsemsdn/sql/percorso.mspx



 
A Torino?


A Torino?
Io vivo e lavoro in provincia di Firenze, ma con gli strumenti di oggi
non credo che la distanza sia un problema.


>>Vincenzo Turturro
Puoi fornirmi un indirizzo telefonico per sentirci in orario di
ufficio? Così puoi parlare anche con il Capo Centro dell'azienda.
Come indirizzi e-mail posso usare V...@Work.it e 
V...@home.it
  ?
Appena posso aprirò un altro thread sull'argomento Access / Run-time /
SQL Server Express, con i primi risultati ottenuti a seguito dei
vostri suggerimenti.
Giorgio DANIELE - Torino


ufficio? Così puoi parlare anche con il Capo Centro dell'azienda.
Manda un messaggio e-mail a questo indirizzo:
v punto turturro chiocciola tiscali punto it
ed io ti risponderò fornendoti il mio numero di telefono.
Sai com'è ... si tratta del cellulare e non intendo renderlo pubblico.
