Post by Stefano CCiao,
io personalmente sottoscrivo in toto ciò che ha scritto Fair87: non
utilizzare mai l'adp, oltre ad essere deprecato, quando le dimensioni
dell'applicativo crescono fa acqua da tutte le parti, a partire dalle
prestazioni.
Non sono affatto d'accordo!
Per me è esattamente il contrario.
Allora, adesso ho bisogno di esprimere tutto quello che penso al riguardo e
tutta la mia (opinabile) esperienza in materia, altrimenti perdo tutte le
mie certezze.
Access via ODBC: usa sia il proprio motore jet che il motore Sql Server per
le query che vengono eseguite sul server
Access adp: NON ha motore interno, quindi tutte le operazioni sui dati
devono PER FORZA essere eseguite lato server.
La conseguenza di tutto ciò è che, secondo me, Access con ODBC non è un
sistema Client-Server puro, Adp invece lo è.
ODBC può vedere le tabelle di Sql Server come tabelle collegate, Adp non le
collega neanche, semplicemente collega una volta per tutto l'intero database
e si interfaccia in modo totale con esso.
In Adp Access è ancora più semplificato rispetto a ODBC.
Facciamo un esempio: ho una tabella collegata di un milione di record e ne
cerco uno solo, se faccio una interrogazione su una maschera, all'interno di
Vba per cercare questo record access tende ad usare il motore Jet e quindi
si comporta da ....Access, facendo transitare tutta la tabella in rete fino
a trovare il record giusto, con enormi rallentamenti, in pratica si comporta
come un sistema File-Server, a meno di non usare query pass-through, ma mi
conviene creare query di questo tipo ogni volta che cerco prestazioni in
rete?
Adp invece, in automatico, delega il motore del server per tutto, senza
preoccuparmi di niente.
Le prime volte che cercavo prestazioni migliori per i miei applicativi in
rete ho cercato di usare ODBC, ma le prestazioni erano deludenti, in più se
volevo velocizzare le query dovevo usare query pass-through oppure viste
memorizzate sul server.
In una normale form ci sono listbox, caselle combinate ecc, ognuna con la
propria origine riga, con Adp imposto la select e so che in ogni caso verrà
eseguita sul server, con ODBC invece dovrei costruire una query p-t ogni
volta, ma chi me lo fa fare?
ODBC è una soluzione a metà strada tra access e sql server, invece Adp usa
il motore sql server per tutto. E' come se fosse un sql server che abbiamo
dotato degli oggetti che gli mancano: forms e reports.
Affidabilità: se partiamo dal presupposto che sql server sia affidabile e
access no, allora meglio Adp. Con Adp non è possibile creare tabelle e query
locali, access non contiene oggetti che possono creare una perdita dei dati.
Fair 87 ha scritto: "quando le dimensioni dell'applicativo crescono fa
acqua da tutte le parti, a partire dalle prestazioni."
Da dove trai questa conclusione? Proprio quando le dimensioni dell'applicativo
crescono Adp risulta vincente. Ho creato un gestionale con 160 form, 80
report, tabelle con centinaia di migliaia di record e l'applicativo va alla
grande da anni.
Mancini ha scritto: "Se nella query ci mettiamo
.... WHERE Campo=Forms!......!..... eccetera
questa non puo essere interpretata da SQLServer quindi tutta la massa di
record della tabella transita nella rete e poi la query viene eseguita da
Access
Se invece nella query ci mettiamo
.... WHERE Campo=" & Forms!......!..... & " eccetera
allora VBA interpreta questa query
e prima di spedirla a SQLServer la traduce cosi:
.... WHERE Campo=5 eccetera
Questa puo essere interpretata direttamente da SQLServer e pertanto nella
rete viaggiano solo i record interessati."
Ecco appunto, perché scervellarsi nel cercare di capire se le query sono
nella forma eseguibile o meno dal server quando invece Adp le esegue tutte
sul server a prescindere?
Con Adp si ha il massimo delle prestazioni in rete. Con sospresa ho scoperto
che i miei programmi in Adp girano anche, anche se con un leggero
rallentamento, anche in reti Vpn via internet, cioè con il computer che
contiene l'applicativo Adp e il server che contiene il database separati da
migliaia di chilometri. Provate a fare questo con ODBC senza infarcire l'applicativo
di centinaia di query PT o di viste residenti sul server create magari solo
per alimentare una singola casella combinata!
Post by Stefano CUsa ODBC e ADO, forms disconnessi (late binding) e query passthrough. E'
un poco (un poco veramente, non in senso ironico!) di lavoro in più
all'inizio, ma ne vale davvero la pena, non ti troverai mai in un vicolo
cieco a chiederti perché qualcosa improvvisamente rallenta o smette di
funzionare.
Non so di cosa parli, in tanti anni mai successo.
Non so perché Microsoft spinga verso ODBC, eppure Adp, essendo in completa
sinergia con Sql Server, dovrebbe contribuire a far usare sempre di più
quest'ultimo. Un motivo per usare ODBC e il poter usare motori di database
diversi da Sql Server, che è poi in fondo una caratteristica che Access
vuole avere dalla nascita, cioè la possibilità di accedere a ogni fonte di
dato.
Rispondo a tmtube:
Effettivamente non mi sento di consigliarti in toto Adp, ma solo perchè
sappiamo che è una soluzione che verrà abbandonata, dal punto di vista
tecnico e pratico invece è da me consigliatisssima. E' anche verò però che
esistono ed esisteranno, spero per tanti anni i Runtime di Access Xp, 2003,
2007, 2010, quindi che supportano tutti Adp, quindi questo formato sarà
utilizzabile per molti anni ancora. L'accoppiata che mi hai proposto, cioè
Access Xp + Sql Server 2012 mi sembra un po' sbilanciata, ti spiego perché.
Ho usato per anni Sql Server 2000, di cui avevo la licenza developer. Poi il
2000 non era più supportato in Vista e ho dovuto cambiare. Ho cercato di
utilizzare per lo sviluppo Sql Server 2008, ma dopo giorni di tentativi non
sono riuscito ad installarlo, quindi ho optato per Sql Server 2005, che va
benissimo per tutte le nostre esigenze. Sql Server è un database molto
potente, in grado di "digerire" tutte le nostre applicazioni, anche in rete
locale con molti client. Usare la versione 2005 secondo me conviene, in
quanto molto più snella della 2008 e, presumo, della 2012, che non ho mai
avuto modo di provare. Attualmente utilizzo: Access Xp e Sql Server Express
2005. Per gestire il database utilizzo Sql Server Management Studio (SSMS).
Sia Sql Express che SSMS sono scaricabili gratuitamente e sono liberamente
utilizzabili. Dal cliente scarico e installo Sql Express 2005 e SSMS e, se
non hanno Access, il Runtime di Access Xp. Un difetto di questa soluzione è
l'impossibilità di gestire gli oggetti del database direttamente da access,
cosa possibile con Access 2007: in questo modo si possono creare tabelle,
query ecc nel database direttamente da Access senza neanche aver bisogno di
SSMS.
Ultimo pensiero, magari non ovvio per chiunque, lo stesso database Sql
Server può essere usato contemporaneamente da applicativi Access ODBC e da
applicativi Adp senza problemi.
Scusate la lunghezza ma il fine del NG è di crescere tutti ed è utile
l'esperienza di ognuno.