Newsgroup: it.comp.appl.access
Titolo: Faqqone, la vendetta  [...perché no...]

Ciao a tutti,
volevo aprire questo tread per il gusto di sapere la vs. opinione.
Ma perché MS non crea un Tool in grado di compilare (meglio assemblare) un 
FE MDB o MDE in un EXE, L'ha fatto con VB (ricordo ancora il VB3)
Installare le runtime è una scocciatura, se non che molti commissionanti 
(purtroppo) vedendo un .MDE pensano che sia si tratti di una soluzione fatta 
da uno smanettone piuttosto che da un programmatore. (credo che tutti vi 
siete trovati in una situazione del tipo "ma l'altro me lo fa in VB o in C 
perché Access è per chi non sa programmare e non è potente. Ovviamente non è 
possibile fare "cultura" con chi ti paga).
L'EXE potrebbe incorporare la VBAxxx.dll oppure il tool potrebbe essere 
richiamanto dal menù strumenti e mostrare un wizard dove collocare le 
librerie? Insomma al posto di avere un intero Framework .NET avere un 
"framework" per access gestibile dall'ambiente.
ATTENZIONE non sto parlando di funzionalità, il RUNTIME funziona, ma di 
comodità e di rendere felici (almeno per quanto mi riguarda) una parte ampia 
degli sviluppatori Access (e cmq per MS si tratta sempre di ricavare 
denaro.)
et voila....  aspetto commenti.
Sam

 "framework" per access gestibile dall'ambiente.
Ti sei praticamente risposto da solo: quasi tutti gli ambienti RAD (anche
.net) non generano .EXE  autonomamente eseguibili ma richiedono
l'installazione di decine (o centinaia) di componenti.
Era così anche per Visual Basic 6.0: i controlli .ActiveX non necessari con
Access e il Runtime di Crystal Reports (soluzione quasi obbligata)
costituivano voluminosi pacchetti d'installazione Runtime.
D'altro canto cosa vorresti: .EXE mostruosi da 100 MB?
La sua (meta) compilazione Access già ce l'ha dalla versione '97:  MDE  :-)
Saluti: Simone

 ha scritto nel messaggio
news:cha2e1$v64$1...@newsreader.mailgate.org...

Non vorrei aver capito male, ma per te il problema non sono i tuoi clienti,
ma sono i tuoi concorrenti che cercano di screditarti parlando male di
Access e di chi lo usa come strumento di sviluppo: penso che se non ti
convinci per primo tu che stanno dicendo una cavolata, difficilmente
riuscirai a convincere i tuoi clienti.
Comunque un paio di frecce nel tuo arco ce l'hai:
1) il numero di licenze vendute di Access nel mondo.
2) Dovresti essere più competitivo della tua concorrenza economicamente
parlando, in quanto, a parità di prestazioni, tu dovresti sviluppare più
velocemente e quindi a minor costo: e penso allora che al tuo cliente non
può fregargliene più di tanto se hai usato Access o no.
Se poi ne fai un problema di affidabilità e performance del Jet di Access,
nessuno ti vieta di usare SQL Server per il BE e Access per l'FE.
Certo se non sono riuscito a convincere te, sicuramente tu non saprei
rintuzzare le obbiezioni del cliente imbeccato dalla tua concorrenza; certo
è che Microsoft non cambierà il modo con cui permette di usare un database
in un computer in cui non è installato Access.
-- 
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 Sam
Credo che il problema fondamentale lo abbia centrato Roberto, non sei sicuro
delle potenzialità dell'accoppaita "SAM"+"ACCESS".
Ciao-
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

 delle potenzialitŕ dell'accoppaita "SAM"+"ACCESS".
Che conosca o non conosca tali potenzialitŕ a mio parere non fa differenza,
in questo caso.
Nel senso che l'utenza aziendale media č talmente "fuori" che non ha proprio
le conoscenze per interessarsi a cosa tu utilizzi per sviluppare.
Se poi qualche allegrone la curiositŕ ce l'ha ... basta rispondere "e' fatto
in Windows", e la faccenda si chiude.
Non č concepibile perder tempo a convincere o non
convincere qualche idiota sugli strumenti di lavoro che prediligi: basta
tutto il
resto.
La cosa cambia (e molto) nel caso si voglia cedere un software e relativi
sorgenti a un rivenditore.

 sorgenti a un rivenditore.
Copncordo tutt'altro discorso.
Ciao.


 Se poi il Cliente ti impone un'ambiente di sviluppo sei tu ad
arretrare...!
In tanti anni di lavoro una figura di cliente siffatta non l'ho incontrata
... e non lavoro con il calzolaio o il piccolo artigiano.
Una buona parte dell'utenza aziendale ancora non riesce a spedire e-mail con
allegati, dubito abbia qualcosa da ridire su Access  :-)
Per il resto _mi ripeto_ è talmente difficile analizzare i loro problemi e
capire cosa vogliono che è inammissibile perdere tempo su questioni legate
all'ambiente di sviluppo.
Ciao: Simone

 Ciao: Simone
Verissimo, credo che la maggior parte del lavoro sia estorcere loro le INFO
giuste per gettare le basi, cosa sempre assai difficile.
In certi casi devo dire beato me..., che non ho questi problemi.
Sviluppo(che parolona) per le esigenze dell'azienda per cui lavoro a tempo
perso.
Ora rileggendo l'ultima mia frase non si capisce se il tempo perso è quello
che passo nell'azienda o se lo sviluppo....!!! ;-)
