Newsgroup: it.comp.appl.access
Titolo: ADP e traffico di rete

Dato che non ho ancora possibilit� di testare adp, mi chiedevo se qualcuno 
avesse un'esperienza del riflesso sulla rete queste operazioni:
- apertura tabella senza utilizzo di select: i dati vengono richiesti in 
massa al server o per paginazione
- propriet� PageSize di ADO pu� alleggerire l'overhead del server
- il cursore rimane lato client o lato server nelle tre situazione: apertura 
tabella, apertura con form mediante select, reportistica
- problema della concorrenza dello stesso record mediante il solo utilizzo 
delle transazini implicite di sql server
- suggerimenti per risparmiare fino all'osso la banda: personalmente cerco 
di utilizzare per i dati pi� o meno statici (anagrafiche) una tabella sul 
client che rinfresco di tanto in tanto. Poi con ADO collegherei la combo box 
ad un mde(mdb) locale quella stessa tabella. Ma � la metodologia pi� 
corretta? Non � che mi sto complicando la vita con inutili pippe mentali?
- in alcuni casi ho bisogno di visualizzare sia in foglio dati, che in 
maschera singola le anagrafiche. Ci sono suggerimenti per risparmiare banda 
e overhead?
Grazie per l'aiuto
Daniele 

 penso che contenga della informazioni che potranno esserti  utili
La mia intenzione era abbandonare ODBC se non per casi estremi, in favore di 
OLE DB o il NON da me approfondito SQL Native Client
Ho pensato nella mia mente che dli ADP avessero un rapporto pi� stretto con 
sql server e quindi candidato a situazioni ottimizzate client/server.
Quindi � da evitare la visualizzazione diretta di tabella e vanno 
privilegiate le tecniche ado con rst.PageSise utitamente a rst.PageCount e 
confezionamento di viste editabili
Per la gestione on-line <-> off-line che ne pensi?
Ti ringrazio per il tuo aiuto
Daniele

 di OLE DB o il NON da me approfondito SQL Native Client
Ma prima ancora d'un discorso prestazionale, hai provato ad agganciare un 
file .ADP al Server DB2 aziendale (� quella, credo, la realt� in cui operi)?
I files .ADP, a meno che non sia cambiato qualcosa col 2007, funzionavano in 
scrittura solo con MS SQL Server.
Ciao: Oscar

 Ciao: Oscar 

 (10000)
Cinzia ti ha esposto sinteticamente ma precisamente la situazione: gli 
snapshot aggiornabili degli .ADP si scaricano localmente (in background) 
tutto il set di records.
Non � chiaro per quale ragione tu pensi che ODBC non operi in modalit� 
"Client/Server": se le queries rispettano le esigenze del driver ODBC le 
interrogazioni vengono sempre eseguite dal Server, restituendo al Client i 
risultati (perfino i classici "filtri tasto destro" vengono eseguiti sul 
Server).
Questa documentazione � forse la migliore in lingua Italiana sull'argomento:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=281
Ciao: Oscar

 Ciao: Oscar
Grazie 

 darmi performance migliori soprattutto al crescere degli utenti.
Che io sappia non esistono tests o prove concrete che dimostrino questa 
tesi.
Del resto se ottieni che le elaborazioni avvengano lato Server, l'incidenza 
sulle performance della metodologia d'accesso usata non contano.
Ciao: Oscar


Vi invito a fare riflessioni su questo articolo 
http://msdn.microsoft.com/en-us/library/ms692882%28VS.85%29.aspx
Anche questa confermata / disattesa / confermata / dalla Microsoft (da un 
po' di tempo)
�
RE: Difference between ADO vs ODBC vs OLE DB
ADO = API to OLE DB.
ADO Speed < OLE DB Speed
Programming the OLE DB API Directly may take a very long time to master.
Explanation from M$.
ActiveX Data Objects (ADO) is a high-level, easy-to-use interface to OLE DB.
OLE DB is a low-level, high-performance interface to a variety of data
stores.
ODBC is another low-level, high-performance (maybe not-so high-performance,
I think) interface that is designed specifically for relational data stores.
ADO provides a layer of abstraction between your client or middle-tier
application and the low-level OLE DB interfaces. ADO uses a small set of
Automation objects to provide a simple and efficient interface to OLE DB.
This interface makes ADO the perfect choice for developers in higher level
languages, such as Visual Basic and VBScript, who want to access data
without having to learn the intricacies of COM and OLE DB.
A Note on Providers from M$:
You are strongly encouraged to use one of the native OLE DB Providers
instead of the Microsoft Open Database Connectivity (ODBC) Provider. Native
OLE DB Providers provide better application stability and performance.
If you want more info, go to 
http://msdn.microsoft.com/data
Then drill down from "Data Access->Reference.
�
Ciao

 po' di tempo)
(cut)
Mi ricordano assai le "tirate" che si leggevano nel 2000 su ADO vs DAO per 
accedere a DB Jet.
Sono discorsi teorici, quasi promozionali, che poi per� si devono valutare 
in scenari reali.
Io insisto nel sostenere, su una base d'esperienza molto pratica, se ottieni 
che le elaborazioni avvengano lato Server non capisco come possa contare 
l'incidenza sulle performance della metodologia d'accesso usata.
Sono sinceramente interessato ad essere smentito con esempi reali..
Secondo me dovresti provare concretamente il funzionamento dei files .ADP e 
la strategia con cui le relative Forms scaricano i dati dal Server 
(strategia non modificabile in alcun modo con ADO, che io sappia).
Sull'argomento ci sono stati in passato thread interessanti sul ng: di certo 
i files .ADP sono controversi e un paio d'anni fa l'orientamento di M$ era 
ambiguo.
Ciao: Oscar

 Ciao: Oscar
Grazie
Ciao 

 davvero hai molto su cui lavorare. Provato!
Avrei molto su cui lavorare se gli .ADP andassero bene per me: ma non vanno 
bene, soprattutto per la modalit� di reperimento dati dal Server.
Quella, sono gradite smentite, non � modificabile: non c'� modo di far 
reperire i records dal Server per "pagina".
Anche il fatto di non potersi connettere in scrittura ad altri DB per il 
sottoscritto � inaccettabile.
Ma alla fine non ho capito bene se li hai provati o no...
Ciao: Oscar

 Ciao: Oscar 

 Un esempio su 
http://www.w3schools.com/ADO/prop_rs_pagesize.asp
No, forse mi sono spiegato male: intendevo un'altra cosa.
Una form agganciata via ODBC richiede dal Server i dati a "pacchetti".
Quindi, su apertura maschera, anche se i records sottostanti fossero milioni 
(e qui si aprirebbe una parentesi MOLTO ampia sul fatto che non dovrebbe 
essere mai cos�) vengono trasferiti sul Client solo i records necessari a 
riempire la videata.
Un discorso analogo durante l'eventuale Scroll della Form.
Inoltre tutti i filtri che si appoggiano sulla propriet� "filter" vengono 
eseguiti lato Server.
Sono strategie di reperimento records efficienti in rete.
La domanda �: sei riuscito a ottenere lo stesso comportamento con un file 
.ADP?
Non *dovrebbe* essere possibile, in alcun modo.
Ciao: Oscar


Come nella "radice" non ho ancora questa possibilit� di testare.
Ma credo che con le tecniche esposte tra cui recordset.Properties("Initial 
Fetch Size") e recordset.Properties("Background Fetch Size")
penso che sono indipendenti dalla connessione e comunque bisognerebbe fare 
una analisi sui adSupport
http://support.microsoft.com/?scid=kb%3Ben-us%3B262311&x=11&y=5
Ciao

 
http://support.microsoft.com/?scid=kb%3Ben-us%3B262311&x=11&y=5
Se riesci a ottenere i risultati sperati, mi raccomando, posta la faccenda 
sul ng.
La cosa � interessante...
Ciao: Oscar


Potete contarci tutti.
Spero di non scoprire l'acqua calda.
Daniele