Discussione:
Access versus Visual Basic. Chiedo aiuto per prendere una decisione importante.
(troppo vecchio per rispondere)
Ludus
2007-04-11 14:34:09 UTC
Permalink
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.
MA
2007-04-11 15:20:06 UTC
Permalink
Post by Ludus
Chiedo aiuto agli esperti. Ho provato a cercare nel Sito Comune ma non
ho trovato un approfondimento sull'argomento.
Ciao Ludus,
la tua analisi è esaustiva ma parte da conoscenze del prodotto Access e
della sua gestione delle licenze errato. Ti consiglio di leggere l'articolo
dedicato
su www.accessgroup.it
Access può essere la tua soluzione, tranquillamente, con dei però.

Primo: Access deve essere solo il front end, devi usare SQL Server come
Backend.
A questo punto non preoccuparti, il tutto ti può costare meno di 500 euro
(con un però)
ma rispondiamo punto per punto

[Cut]
Post by Ludus
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.
[CUT]

Qui devi scegliere se usare AS400 collegato come Backend per tutti o usare
un db SQL, uno solo, anche nella versione Express (cioè free) che curi il
collegamento tra i client e AS400. Io ti suggerisco quest'ultima soluzione
anche perchè così esponi ad internet un db di passaggio e non il db server
(è il principio delle carte di credito prepagate, se interettano quelle il
danno è limitatissimo)
Post by Ludus
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.
Esiste un tool che si chiama Developer kit fino ad Access xp e Visual Studio
Tools for Application le versioni A2003: dalla versione A2007 sarà
addirittura free e quindi decade anche il costo. Questo tool ti permette di
distribuire un ambiente runtime che permette di far girare la tua
applicazione a costo zero. C'è un inconveniente A2003 non gira su S.O.
precedenti a W2000 quindi ti serve Access xp developer. Lo potrest trovare
anche su ebay a costi irrisori.
E' lo stesso che avviene con VB, cmq devi distribuire il runtime VB.
Post by Ludus
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.
Tu confondi Access come backend e Access come Front End.
Ti suggerisco quindi SQL Express (N.B. GRATUITO) come database locale e
Access come GUI cioè maschere, query, report e codice.
Post by Ludus
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.
Sensazione errata. Il P-code generato dal'mde è ininterpretabile. L'anno
scorso abbiamo assistito ad un esperimento di un geniaccio di access,
credimi sicuramente non alla portata di tutti e cmq riuscirebbe a crackare
anche un programma VB o altro, ma aveva bisogno di alcuni accorgimenti,
tolti i quali (e nessuno li mette normalmente quando sviluppa) l'mde è
ancora tranquillamente inviolabile al pari di un programma compilato.
Post by Ludus
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.
beh questo non è verissimo, potresti spezzetare l'applicazione in diversi db
a seconda di quello che ti serve e sostituire di volta in volta solo ciò che
ti serve
Post by Ludus
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.
SQL Express appunto
Post by Ludus
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.
Convinzione errata. Il 3 maggio ci sarà un webcast su questa soluzione e
vedrai come è semplice. Tra l'altro alla Cisa, Giorgio farà un intervento su
Access+ SQL Server + ODBC, che ti consiglio di seguire
Post by Ludus
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.
Questo è vero, ma il db access non è consigliabile
Post by Ludus
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.
Perfetto, tra l'altro loro avrebbero anche il runtime e quindi eventuali
nuove macchine sarebbe subito licenziate.
Post by Ludus
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.
Ti posso rassicurare con comprensibile tranquillità. Poi bisogna capire cosa
sai/sanno fare con access
Post by Ludus
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.
Se hai problemi o dubbi continuare a chiedere
--
--
Massimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access
Ludus
2007-04-11 21:06:17 UTC
Permalink
... OMISSIS ...
Post by MA
Se hai problemi o dubbi continuare a chiedere
--
Grazie per ora.
Leggerò con attenzione e mi informerò su quanto mi hai detto, poi mi
farò sicuramente risentire.

Ciao
Ludus
2007-04-12 20:52:37 UTC
Permalink
On Wed, 11 Apr 2007 17:20:06 +0200, "MA"
Post by MA
Post by Ludus
Chiedo aiuto agli esperti. Ho provato a cercare nel Sito Comune ma non
ho trovato un approfondimento sull'argomento.
Ciao Ludus,
la tua analisi è esaustiva ma parte da conoscenze del prodotto Access e
della sua gestione delle licenze errato. Ti consiglio di leggere l'articolo
dedicato
su www.accessgroup.it
Su Accessgroup ho trovato il tuo articolo "Posso distribuire il
runtime?". Ti riferisci a questo? Runtime e Office Developer? E' tutto
un po' complicato, e mi è parso che ci siano delle limitazioni... ma
approfondirò senz'altro, anche se è probabile che avrò bisogno di
qualche altro aiutino.
Post by MA
Access può essere la tua soluzione, tranquillamente, con dei però.
Primo: Access deve essere solo il front end, devi usare SQL Server come
Backend.
A questo punto non preoccuparti, il tutto ti può costare meno di 500 euro
(con un però)
Riprendo l'argomento più sotto.
Post by MA
ma rispondiamo punto per punto
[Cut]
Post by Ludus
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.
[CUT]
Qui devi scegliere se usare AS400 collegato come Backend per tutti o usare
un db SQL, uno solo, anche nella versione Express (cioè free) che curi il
collegamento tra i client e AS400. Io ti suggerisco quest'ultima soluzione
anche perchè così esponi ad internet un db di passaggio e non il db server
(è il principio delle carte di credito prepagate, se interettano quelle il
danno è limitatissimo)
D'accordo. Per l'SQL riprendo più avanti.
Post by MA
Post by Ludus
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.
Esiste un tool che si chiama Developer kit fino ad Access xp e Visual Studio
Tools for Application le versioni A2003: dalla versione A2007 sarà
addirittura free e quindi decade anche il costo. Questo tool ti permette di
distribuire un ambiente runtime che permette di far girare la tua
applicazione a costo zero. C'è un inconveniente A2003 non gira su S.O.
precedenti a W2000 quindi ti serve Access xp developer. Lo potrest trovare
anche su ebay a costi irrisori.
E' lo stesso che avviene con VB, cmq devi distribuire il runtime VB.
Come sopra: devo capire bene tutto ciò.
Post by MA
Post by Ludus
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.
Tu confondi Access come backend e Access come Front End.
Ti suggerisco quindi SQL Express (N.B. GRATUITO) come database locale e
Access come GUI cioè maschere, query, report e codice.
SQL Express è un subset di SQL Server o è un'altra cosa?
Quel che non capisco è perchè sei così tassativo nel consigliarmi SQL
(Express o Server), al posto della gestione data-base di Access. Io
sono anni che uso il db back-end di Access (con il motore Jet, si dice
così?) senza problemi. E' efficiente e sicuro. Non ho mai perso un
record. Pur conoscendo pochissimo il SQL Server, questo mi sembra
molto più complicato.

Domande conseguenti. Ammesso che io abbia Access come front-end e un
SQL (Express o Server) come back-end (così come da te consigliato),
avrò la stessa facilità di accesso alle tabelle? Mi riferisco in
particolare alla possibilità di costruire comandi sql tamite la
modalità grafica così facile e potente di Access nel predisporre le
"query"? E avrò le stesse ottime performances negli accessi ai dati?
Dovrò accedere all'SQL tramite ODBC? Non peggiorano i tempi di
risposta? Non mi impegolerò nelle cosiddette (non mi viene la parola)
???-procedures?
Post by MA
Post by Ludus
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.
Sensazione errata. Il P-code generato dal'mde è ininterpretabile. L'anno
scorso abbiamo assistito ad un esperimento di un geniaccio di access,
credimi sicuramente non alla portata di tutti e cmq riuscirebbe a crackare
anche un programma VB o altro, ma aveva bisogno di alcuni accorgimenti,
tolti i quali (e nessuno li mette normalmente quando sviluppa) l'mde è
ancora tranquillamente inviolabile al pari di un programma compilato.
D'accordo. Ciò mi tranquillizza.
Post by MA
Post by Ludus
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.
beh questo non è verissimo, potresti spezzetare l'applicazione in diversi db
a seconda di quello che ti serve e sostituire di volta in volta solo ciò che
ti serve
Anche qui temo di essere impreparato. Oggi ho fatto anche qualche
ricerca nell'Help in linea, ma non ho trovato quanto cercavo. In poche
parole, se apro un programma base, che deve lanciare di volta in volta
uno dei diversi pezzetti come tu mi consigli, come si può fare? C'è un
comando dipo Shell o simile? Call? O che so?
Post by MA
Post by Ludus
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.
SQL Express appunto
Ah, ma allora insisti... (Non so fare la faccina scherzosa).
Post by MA
Post by Ludus
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.
Convinzione errata. Il 3 maggio ci sarà un webcast su questa soluzione e
vedrai come è semplice. Tra l'altro alla Cisa, Giorgio farà un intervento su
Access+ SQL Server + ODBC, che ti consiglio di seguire
Che cosa è il "webcast" e come posso seguirlo il 3 maggio? Anche
l'intervento di Giorgio alla Cisa, dov'è?
Post by MA
Post by Ludus
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.
Questo è vero, ma il db access non è consigliabile
Repetita juvant...
Post by MA
Post by Ludus
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.
Perfetto, tra l'altro loro avrebbero anche il runtime e quindi eventuali
nuove macchine sarebbe subito licenziate.
OK.
Post by MA
Post by Ludus
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.
Ti posso rassicurare con comprensibile tranquillità. Poi bisogna capire cosa
sai/sanno fare con access
Ne ho parlato con il Capo Centro e l'ho visto disponibilissimo. Tra
parentesi è lui che ha scritto tutta l'applicazione in Clipper ed è
uno in gamba.
Post by MA
Post by Ludus
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.
Se hai problemi o dubbi continuare a chiedere
Come vedi...
Ciao e grazie.
Post by MA
--
MA
2007-04-13 08:13:38 UTC
Permalink
Post by Ludus
On Wed, 11 Apr 2007 17:20:06 +0200, "MA"
Post by MA
Post by Ludus
Chiedo aiuto agli esperti. Ho provato a cercare nel Sito Comune ma
non ho trovato un approfondimento sull'argomento.
Ciao Ludus,
Su Accessgroup ho trovato il tuo articolo "Posso distribuire il
runtime?". Ti riferisci a questo? Runtime e Office Developer? E' tutto
un po' complicato, e mi è parso che ci siano delle limitazioni... ma
approfondirò senz'altro, anche se è probabile che avrò bisogno di
qualche altro aiutino.
Sì quello. Non ci sono grandi limitazioni. L'unica è la scelta della
versione, se hai pc con win '98 devi trovare xp developer.
Post by Ludus
SQL Express è un subset di SQL Server o è un'altra cosa?
Quel che non capisco è perchè sei così tassativo nel consigliarmi SQL
(Express o Server), al posto della gestione data-base di Access. Io
sono anni che uso il db back-end di Access (con il motore Jet, si dice
così?) senza problemi. E' efficiente e sicuro. Non ho mai perso un
record. Pur conoscendo pochissimo il SQL Server, questo mi sembra
molto più complicato.
SQL Express è una versione limitata di Sql. E' la versione aggiornata di
MSDE, ma diverso nelle limitazioni. La prima più importante: MSDE deteriora
le prestazioni dopo 5 utenti contemporanei (in pratica era solo un modo per
approcciarsi a SQL, anche se ho visto applicazioni che funzionano benissimo
con MSDE anche con molti + utenti); con SQL Express 2005 no nhai problemi
del genere, hai solo la limitazione di lavorare su di 1 Gb di Ram (anche se
il server ne montasse di più) e con un solo processsore (anche qui a
dispetto della configurazione del server); inoltre un db Sql è al massimo di
4 GB (access lo è di 2 GB). Nel tuo caso queste limitazioni non sarebbero
sofferte, perchè SQL è slo il collettore per rversare tutto sul server
AS400, quindi lo riempi e l svuoti come vuoi.
Anche io lavoro da anni con gli MDB, ma visto la qualità del servizio di SQL
e l'esiguità di inconvenienti (quasi zero) non ha più senso. Un altro motivo
è la possibilità con sql di creare una rete geografica attraverso una VPN
(con Access è improponibile): metti che vuoi fare una ricerca tipo come è la
giacenza in real time di quel prodotto? In un attimo ce l'hai e la verifichi
con la giacenza che riulta sul server.
Post by Ludus
Domande conseguenti. Ammesso che io abbia Access come front-end e un
SQL (Express o Server) come back-end (così come da te consigliato),
avrò la stessa facilità di accesso alle tabelle? Mi riferisco in
particolare alla possibilità di costruire comandi sql tamite la
modalità grafica così facile e potente di Access nel predisporre le
"query"? E avrò le stesse ottime performances negli accessi ai dati?
Dovrò accedere all'SQL tramite ODBC? Non peggiorano i tempi di
risposta? Non mi impegolerò nelle cosiddette (non mi viene la parola)
???-procedures?
Sì, assolutamente la stessa. Tu lavori in ambiente Access e quindi non hai
problemi. In più hai la possibilità di usare le query PT cioè delle query
che lvorano diettamente sul server e quindi spaventosamente più veloci.
I driver ODBC assolutamente non rallentano le prestazioni, ovvio che però
devi costruire bene il tutto.
Post by Ludus
Post by MA
beh questo non è verissimo, potresti spezzetare l'applicazione in
diversi db a seconda di quello che ti serve e sostituire di volta in
volta solo ciò che ti serve
Anche qui temo di essere impreparato. Oggi ho fatto anche qualche
ricerca nell'Help in linea, ma non ho trovato quanto cercavo. In poche
parole, se apro un programma base, che deve lanciare di volta in volta
uno dei diversi pezzetti come tu mi consigli, come si può fare? C'è un
comando dipo Shell o simile? Call? O che so?
L'idea è quella di creare applicazioni separate. Una per il FE delle casse,
uno o più per gli uffici, una per il magazzino, etc. Poi ti crei una
applicazione di navigazione e attraverso quella gestisci il tutto. ovvio che
così puoi cambiare i pezzi che credi.
Oppure, io faccio così, creo dei Service pack, dei piccoli db che lanciati,
cancellano, sostituiscono o aggiungono oggetti tipo form, moduli, report o
altro, oppure aggiornano valori. Quindi tu invii quest aggiornamenti e loro
fanno tutto dopo aver fatto un bel backup della versione da aggiornare.

ma da qualche parte ho letto che hai l'adsl, quindi non hai nessunissimo
problema. Tra l'altro con la famosa VPN (o anche usando software free come
Hamachi) puoi fare anche assistenza remota e cioè dal tuo ufficio sistemi il
problema dell'applicazione che gira a Canicattì, io ho mie applicazioni che
girano ad Hong Kong e credimi non è che vado una settimana sì ed una no.
Post by Ludus
Post by MA
SQL Express appunto
Ah, ma allora insisti... (Non so fare la faccina scherzosa).
;-)
Post by Ludus
Post by MA
Convinzione errata. Il 3 maggio ci sarà un webcast su questa
soluzione e vedrai come è semplice. Tra l'altro alla Cisa, Giorgio
farà un intervento su Access+ SQL Server + ODBC, che ti consiglio di
seguire
Che cosa è il "webcast" e come posso seguirlo il 3 maggio? Anche
l'intervento di Giorgio alla Cisa, dov'è?
I Webcast sono dimostrazioni online
http://www.microsoft.com/italy/eventi/default.mspx
tra non molto verrà pubblicato anche l'appuntamento di cui ti parlavo. Per
seguirli ti basta Windows Media Player.

La Cisa è una conferenza che si terrà a Milano, info le trovi su
www.accessgroup.it
Post by Ludus
Post by MA
Post by Ludus
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.
Ti posso rassicurare con comprensibile tranquillità. Poi bisogna
capire cosa sai/sanno fare con access
Ne ho parlato con il Capo Centro e l'ho visto disponibilissimo. Tra
parentesi è lui che ha scritto tutta l'applicazione in Clipper ed è
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.
;-)
--
--
Massimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access
Ludus
2007-04-15 10:35:33 UTC
Permalink
On Fri, 13 Apr 2007 10:13:38 +0200, "MA"
<***@massimilianoamendola.it> wrote:

... Omissis ...
Post by MA
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.
VT @ home
2007-04-16 09:31:44 UTC
Permalink
(.....)
On Fri, 13 Apr 2007 10:13:38 +0200, "MA"
... Omissis ...
Post by MA
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?
Perchè è un RDBMS vero, quindi offre pieno supporto alle transazioni, alle autorizzazioni utente, alle stored procedure,
ai trigger ...
Alcune di queste funzionalità sono presenti anche in Access, ma implementate in maniera più "artigianale", tenuto conto
anche del fatto che Access è nato come DBMS per uso personale, mentre SQL è nato come risposta ad Oracle in ambito
aziendale.
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.
Vincenzo Turturro
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
Ludus
2007-04-19 15:07:12 UTC
Permalink
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
VT @ home
2007-04-19 19:15:10 UTC
Permalink
Post by Ludus
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
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.
Vero.
Ove per "coerente come S.O." si intenda "con sistema operativo compatibile con la versione runtime di Access adottata"
Post by Ludus
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.
Chi sviluppa dovrà acquisire anche una licenza Office 2003 completa di Access.
Post by Ludus
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.
Vero
Post by Ludus
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.

Post by Ludus
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.
Vero
Post by Ludus
---------------------------------------------------------------------------------------------
- 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?
Lo scarichi da questo link:
http://www.microsoft.com/downloads/details.aspx?displaylang=it&FamilyID=220549b5-0b07-4448-8848-dcc397514b41
Per la documentazione e/o l'addestramento iniziale ci sono le registrazioni di alcuni webcast reperibili sul sito
Microsoft.
E poi potresti venire alla CISA a MIlano il 7/8 giugno p.v. !
http://www.accessgroup.it/index2.asp?ID=221&ID_Coll_Menu=221&Titolo=<B>CISA%202007</b>%20(Cisa3)
dove fra l'altro è prevista anche una sessione dedicata ll'interfacciamento fra Acces e SQL Server.
Post by Ludus
- Serve anche "SQL Server Management Studio Express" che è indicato
nello stesso sito?

Post by Ludus
- "Visual Studio Tools for Application" per Access 2003 (S.O. Windows
XP) occorre acquistarlo presso un rivenditore di software?

Post by Ludus
Inoltre saremo in grado noi come centro di sviluppo aziendale di utilizzarlo
oppure occorre un aiuto specialistico?
Credo che non dovreste avere particolari problemi.
Post by Ludus
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.
Se servisse, io ho ottime conoscenze sia in ambito iSeries (AS/400) ed Access oltre che Clipper.
Post by Ludus
-------------------------------------------------------------------------------------------------
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?
No, però una stored procedure ha il vantaggio di "girare" sul server invece che in locale, per cui i dati che viaggiano
sulla rete sono solo quelli restituiti dall'istruzione SQL.
Quindi fai tu le debite considerazioni riguardo alle prestazioni di una query Access rispetto ad una stored procedure.
Post by Ludus
I "trigger" poi, che diavoleria sono?
Un trigger è una funzione, scritta in un particolare linguaggio proprietario del DBMS, la cui esecuzione viene associata
al verificarsi di particolari eventi su determinate tabelle.
Per esempio puoi definire un trigger che al verificarsi della cancellazione di un record da una certa tabella salva il
record in una tabella di backup in modo da mantenere una copia.
E' ovvio il vantaggio dei trigger: chiunque, uomo o programma, esegua un'operazione su una tabella di un db, il trigger
esegue le azioni stabilite.
In questo modo puoi implementare tutta una serie di funzioni a livello del db e non a livello applicativo, con gli ovvi
vantaggi di manutenibilità.
Post by Ludus
-----------------------------------------------------------------------------------------------------
Grazie e saluti a tutti
Giorgio DANIELE - Torino
Vincenzo Turturro
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
Ludus
2007-04-19 20:35:27 UTC
Permalink
On Thu, 19 Apr 2007 21:15:10 +0200, "VT @ home" <***@home.it> wrote:
.
... OMISSIS ...
Post by VT @ home
Se servisse, io ho ottime conoscenze sia in ambito iSeries (AS/400) ed Access oltre che Clipper.
A Torino?
Post by VT @ home
Post by Ludus
Giorgio DANIELE - Torino
Vincenzo Turturro
---------------------------------------------
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
VT @ Work
2007-04-20 06:17:12 UTC
Permalink
Post by Ludus
.
... OMISSIS ...
Post by VT @ home
Se servisse, io ho ottime conoscenze sia in ambito iSeries (AS/400) ed Access oltre che Clipper.
A Torino?
Io vivo e lavoro in provincia di Firenze, ma con gli strumenti di oggi
non credo che la distanza sia un problema.
Post by Ludus
Post by VT @ home
Post by Ludus
Giorgio DANIELE - Torino
Vincenzo Turturro
---------------------------------------------
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
Ludus
2007-04-23 07:36:14 UTC
Permalink
Post by VT @ Work
Io vivo e lavoro in provincia di Firenze, ma con gli strumenti di oggi
non credo che la distanza sia un problema.
Post by VT @ home
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 ***@Work.it e ***@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
Post by VT @ Work
Post by VT @ home
---------------------------------------------
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
VT @ home
2007-04-24 06:57:37 UTC
Permalink
Post by Ludus
Post by VT @ Work
Io vivo e lavoro in provincia di Firenze, ma con gli strumenti di oggi
non credo che la distanza sia un problema.
Post by VT @ home
Vincenzo Turturro
Puoi fornirmi un indirizzo telefonico per sentirci in orario di
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.
Post by Ludus
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
Post by VT @ Work
Post by VT @ home
---------------------------------------------
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
VT @ home
2007-04-19 19:25:52 UTC
Permalink
(.....)
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


Vincenzo Turturro
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
VT @ home
2007-04-11 15:32:06 UTC
Permalink
(.....)
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.
No.
Se usi i tool di sviluppo di Office puoi distribuire il runtime di Access insieme alla tua applicazione, senza pagare
alcuna licenza aggiuntiva e senza preccuparti della presenza di Office e/o Access sul computer di destinazione.
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.
No.
Se l'applicazione è ben ingegnerizzata e progettata, se non fai uso di componenti esterne (ocx ecc.) è stabile nè più nè
meno di un programma compilato.
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.
No. In ogni caso (è successo molto raramente) basta ripristinare la copia originale.
Magari ogni volta all'accensione del pc.
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.
Dipende anche dalla frequenza degli aggiornamenti.
Perchè non collegare i negozi via ADSL all'AS/400 su VPN ?
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.
Nessun problema di licenza: esiste la versione Express che è addirittura free.
Per la facilità d'uso ... basta un minimo di familiarità.
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.
Vedi risposta la punto 1.
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.
Mi lascia perplesso il fatto che tu non conosca Visual Basic.
Con Access da solo, senza conoscere VBA (che di fatto è una versione di Visual Basic), si va veramente poco lontano ...
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.
Vincenzo Turturro
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
Ludus
2007-04-11 21:04:07 UTC
Permalink
... OMISSIS ...
Post by VT @ home
Mi lascia perplesso il fatto che tu non conosca Visual Basic.
Con Access da solo, senza conoscere VBA (che di fatto è una versione di Visual Basic), si va veramente poco lontano ...
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
Post by VT @ home
---------------------------------------------
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
Ludus
2007-04-12 21:05:13 UTC
Permalink
Post by VT @ home
(.....)
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.
No.
Se usi i tool di sviluppo di Office puoi distribuire il runtime di Access insieme alla tua applicazione, senza pagare
alcuna licenza aggiuntiva e senza preccuparti della presenza di Office e/o Access sul computer di destinazione.
Anche "MA" di Accessgroup ha risposto al mio quesito più o meno allo
stesso modo. Cercherò di approfondire bene e se non ce la faccio da
solo tornerò a chiedere aiuto.
Post by VT @ home
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.
No.
Se l'applicazione è ben ingegnerizzata e progettata, se non fai uso di componenti esterne (ocx ecc.) è stabile nè più nè
meno di un programma compilato.
D'accordo, credo alla tua esperienza che mi tranquillizza.
Post by VT @ home
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.
No. In ogni caso (è successo molto raramente) basta ripristinare la copia originale.
Magari ogni volta all'accensione del pc.
Idem come sopra.
Post by VT @ home
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.
Dipende anche dalla frequenza degli aggiornamenti.
Perchè non collegare i negozi via ADSL all'AS/400 su VPN ?
In effetti i negozi sono già collegati cia ADSL, e quindi 6 o 7 mega
alla fin fine non sono poi un granchè.
Post by VT @ home
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.
Nessun problema di licenza: esiste la versione Express che è addirittura free.
Per la facilità d'uso ... basta un minimo di familiarità.
Ho commentato e chiesto ulteriori spiegazioni sull'argomento a "MA" di
Accessgroup che ha risposto ai miei quesiti, come gentilmente hai
fatto tu. Va tutto così liscio con SQL Express? Se è così, bene. Però
non riesco a capire perchè entrambi mi sconsigliate il db back-end di
Access che va così bene!... ed è così facile da usare!...
Post by VT @ home
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.
Vedi risposta la punto 1.
OK.
Post by VT @ home
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.
Mi lascia perplesso il fatto che tu non conosca Visual Basic.
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.
Post by VT @ home
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.
Vincenzo Turturro
---------------------------------------------
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------
Continua a leggere su narkive:
Loading...