Newsgroup: it.comp.appl.access
Titolo: Access Data Projects:  futuro incerto

Le perplessità che molti sviluppatori hanno sollevato sulle aree Access
(italiane e straniere) relativamente agli .ADP, sembrano trovare conferma
nel BLOG relativo al prodotto:
http://blogs.msdn.com/access/archive/2006/05/19/602128.aspx#comments
Clint Covington fa capire che, in pratica, i files di progetto ADP non
saranno prioritari nelle future versioni di Access: verrano supportati ma
quasi controvoglia.
E l'ipotesi che prima o poi facciano la fine delle DAP non viene smentita.
Consiglia esplicitamente di non utilizzarli per i nuovi progetti: va da sè
che tra qualche anno potrebbero ripensarci, dati i precedenti!
Simone Calligaris

Ho letto il blog che hai segnalato.
Sinceramente sono un po' preoccupato per questa (sembrerebbe certa) decisione 
di lasciar morire gli ADP.
Credo che l'accoppiata Access + SQL Server (via OLE DB) al momento sia la 
migliore soluzione per permettere, a chi ha passato diverso tempo su Access 
con gli MDB, di passare ad un RDBMS più stabile, sicuro e performante come 
SQL Server.
Probabilmente in casa Microsoft vogliono indurre gli sviluppatori a passare 
alle tecnologie .NET ed al provider SQL Native Client, relegando Access ad 
uno strumento "inferiore", utilizzato magari in ambiti prevalentemente NON 
di rete, dove la sicurezza non è così importante e non è richiesto un alto 
livello di sicurezza ed affidabilità.
Se questa paventata idea dovesse trasformarsi in una decisione definitiva 
sarei veramente dispiaciuto.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution

 livello di sicurezza ed affidabilità.
Forse, ma si deve prendere atto di tre fatti:
1) Non credo siano molti gli sviluppatori che lavorano per Wall Street: per
le realtà aziendali "comuni" basta e avanza la vecchia modalità ODBC (chi
dice il contrario, parla per sentito dire).
Ma se rimaniamo a livello italico, direi che nella maggioranza dei casi
può bastare perfino Jet.
D'altra parte pochissimi gestionali aziendali risultano, a oggi, sviluppati
con .NET nonostante facciano egregiamente il loro lavoro.
2) Lo sviluppo del futuro potrebbe essere orientato verso il web, quindi le
tecnologie Desk diverrebbero comunque sconsigliabili (compresi ADP e Windows
Forms di .NET)
3) In ogni caso Access va avanti: e le stesse indiscrezioni che avvisano sui
rischi d'utilizzo degli ADP, parlano di un prodotto che sarà comunque
mantenuto in linea con i tempi: il che include il framework .NET e
probabilmente la possibilità d'esportare i progetti di Access direttamente
in Visual Studio.
La prossima versione di Windows ci darà grattacapi per un lustro, però è
innegabile che sia un mondo nuovo e questo influirà sulle applicazioni col
tempo.
Non mi pare irrealistica l'Ipotesi di un Office 20XX basato sull'interfaccia
"Avalon" di Vista, programmabile con linguaggi .NET e che usi per
l'archiviazione predefinita non .MDB o ACCDB ma semplicemente il file system
di Windows (basato su SQL Server come sappiamo).
Etc.
Ciao, Simone

 (compresi ADP e Windows Forms di .NET)
Probabilmente è vero: andiamo verso un mondo sempre più "connesso" e forse 
utilizzeremo sempre più web services che DLL.
Tuttavia, penso che per un programmatore Access (MDB) sia molto più semplice 
"aggiornare" le sue conoscenze passando prima attraverso ADP+SQL Server per 
arrivare a .NET e SQL Native Client, piuttosto che saltare direttamente a 
Visual Studio.


 tua stessa opinione e lui non parla per sentito dire.
Nemmeno io: e li ADP li ho usati, eccome.
Ciao, Simone

 
http://blogs.msdn.com/access/archive/2006/05/19/602128.aspx#comments
Sembra che la MS voglia dare una grossa mano d'aiuto ai propri concorrenti.
La semplicità di sviluppo Access/SQL tramite adp è superata solo dallo 
sviluppo di un mdb ma la stabilità e la sicurezza di SQL sono estremamente 
superiori: al di là delle prestazioni (cosa non da poco) si consideri che un 
mdb lavora in file sharing e quindi il file è fisicamente accessibile da 
chiunque acceda al database mentre con SQL devi conoscere utente e password 
solo per vedere i dati mentre il file è assolutamente inaccessibile.
Per non parlare della semplicità con cui si condivide lo stesso database SQL 
tra gli utenti locali e gli utenti web senza calo di prestazioni.
Io credo che spesso capita che chi sviluppa linguaggi di programmazione si 
perda nel proprio mondo fatto di "continue migliorie" e non capisca che fa 
perdere la bussola a chi lavora con un certo prodotto.
Vabbè... lasciamo perdere....
Ciao
Davide
-- 
www.gestionedati.com