Newsgroup: it.comp.appl.access
Titolo: ODBC..ke lentezza!

Salve..Problema:
Ho creato un programma che lavora su delle tabelle collegate in ODBC 
all'as400..Per questo nessun problema..E' logico che quando vado a 
salvare,consultare o visualizzare dei dati su quelle tabelle il 
programma si rallenta un pò..Il problema è che il pgm gira lentamente 
anche quando non interagisco con quelle tabelle,ad esempio quando 
inserisco dei dati in edit che non sono collegati ODBC..Utilizzo 
l'ultima versione del Client Access,con Office XP!E' possibile questo?
C'è una qualche proprietà da settare per evitare la lentezza di tutto 
il pgm?Grazie 1000!
Inviato da 
www.mynewsgate.net

 ha scritto nel messaggio
news:200406301...@mynewsgate.net...

Se crei delle query nel db su tabelle collegate via ODBC l'efetto
collaterale è che mostruosamente tutti i dati delle tabelle vengono
scaricati sll'host e poi viene effettuato il join anche su milioni di
righe... e magari ne servono solo poche. Jet funziona solo in questo modo.
Non ne parliamo per le connessioni remote.
Devi interagire con as/400 creandoti SQL pass through. Ciò comporta la
conoscenza di SQL/400. Le SPT vengono compilate, eseguite e restituite da
As/400.
Oppure buttarti sugli ADO con connessioni ODBC.... Crearti degli archivi
"off line" da sincronizzarti di tanto in tanto per migliorarti le
prestazioni sui report e sulle machere. Oppure affiancareun'altro as/400
utilizzato solo come interfaccia... e su questo IBM si sbizzarrisce. Poi ci
sono soluzioni moooooolto più onerose.
La regola è "chiedi ciò che serve veramente".  Devi dimenticare la logica di
Jet ed evitare di trapiantarla su As/400... è un suicidio... oltre che
attireresti imprecazioni a non finire da parte degli utenti.
Spero di esserti stato utile
Ciao.

 righe... e magari ne servono solo poche. Jet funziona solo in questo modo.
E' evidente che tu del funzionamento di jet non conosci nulla.
La gestione delle tabelle collegate è fatta secondo uno schema decisionale
che jet applica alla sintassi della query. Se la query jet è 100% compliant
con il set delle capabilities ODBC implementate nel driver, allora la query
viene trasformata da jet stesso in una query pass-thru a tutti gli effetti.
Esempio.
SELECT count(*) FROM tabella WHERE key LIKE '*pippo*'
semplificando al massimo, viene interpretata da jet come segue:
1) il driver ODBC supporta la funzione count()?
2) il driver ODBC supporta l'operatore LIKE? E con quale whildchar?
...
Se tutto è ok la query viene mandata al server, sostituendo il '*' con il
whildchar supportato (ad es. il '%').
Certamente non viene portata in locale tutta la tabella e computato il
count(*) sulla tabella locale ...
Diverso il caso di una query del tipo
SELECT miafunct(key) FROM tabella WHERE key LIKE '*pippo*'
In tal caso miafunct (che supponiamo essere una funzione VBA) non è
supportata dal server (e non è implementata nel set di funzioni ODBC), e la
query viene eseguita portando in locale i dati.
Attenzione. Jet non è così cretino da portarsi in locale TUTTA la tabella,
MA SOLO I RECORD CHE SODDISFANO LA CONDIZIONE WHERE!
BTW, c'è un rete un ottimo white-paper sul funzionamento di jet e su come
ottenere risultati ottimali con Access e le tabelle collegate ODBC.
Ad ogni buon conto, se proprio non ti va di leggere questo white-paper, puoi
fare due prove e renderti conto che ciò che credi non è vero.
Sandro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 ha scritto nel messaggio
news:212Z210Z230Z116Y...@usenet.libero.it...

Mi riferivo essenzialmente sul comportamento delle join che è davvero
penoso.
In ogni caso ho monitorato il traffico di rete in tutte le situazioni e jet
ha avuto sempre la peggio nelle tabelle di comparazione prestazioni e
quantità dati restituiti. Le SPT hanno sempre dato risultati migliori nel
99% dei casi.
Le semplici query di selezione su singola tabella hanno prestazioni quasi
equivalenti, ma i package in questo contesto fanno la loro parte e fanno
coincidere quasi le prestazioni nelle diverse situazioni se reiterate nel
tempo.
Jet imposta i cursori sempre a livello locale per default (vedi equiv. ado
adUseClient). Jet non è nato per interagire con as/400 né si toglie nulla ai
suoi meriti.
SPT in SQL/400 fa il suo dovere anche in query molto complesse.
Ciao


 equivalenti,
Non è vero neanche questo. Su tabelle molto popolose la versione jet è di
gran lunga migliore se hai a che fare con un dynaset, equivalente se con una
snapshot. Infatti jet si fa una lookup della PK (cosa che nel server
equivale ad una index-scan) e poi legge su PK i soli record visualizzati, ad
esempio, in un datagrid o in una form associata.
BTW, analizzati il log di un'applicazione access FE e un BE con, ad es.,
mysql e ti rendi conto che ciò che sostieni non è vero.
Sandro.


 Inviato via 
http://arianna.libero.it/usenet/
A questo punto devo pensare che è il driver odbc che fa cilecca.
Tutto ciò che ho affermato l'ho provato direttamente riportando su una
tabella di comparazione.
Probabilmente il driver odbc per l'os 4.4.0 ha dei problemi di digestione.
Sei al corrente?
Ciao

OneEDP ha scritto:
Complimenti per la discussione tecnica... finalmente qualcosa di serio...
ci č piaciuta, anzi ci sta piacendo... 
Spiacente OneEDP, ma sono pienamente daccordo con Sandro... Jet č Jet e
fino a prova contraria non si tocca. 
Continuate, continuate...
-- 
Pablitomf
Lentamente muore chi abbandona un progetto prima di iniziarlo, chi non fa
domande sugli argomenti che non conosce, chi non risponde quando gli
chiedono qualcosa che conosce. (P.Neruda)
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 A questo punto devo pensare che è il driver odbc che fa cilecca.
Non lo escludo. Io ti porto la mia personale esperienza con i driver MyODBC,
che implementano un set piuttosto ristretto di features, ma quelle poche le
implementano in modo davvero molto raffinato.
Prova a dare un'occhiata a:
http://www.microsoft.com/accessdev/articles/Jet3ODBC.htm
Non è l'articolo a cui accennavo sopra, ma credo che nella sostanza dica le
medesime cose.
Ciao, Sandro.



Onori e meriti a Jet. Se non fosse per Jet, Access non esisterebbe ok.
Prima di fare affermazioni, ho sempre provato sulla pellaccia i risultati e
ancora oggi quando ho la tentazione di utilizzare Jet per as/400 i risultati
sono deludenti. Provando ad utilizzare driver ODBC non IBM addirittura c'è
un incremento di prestazioni che Jet si sogna.
Quando si scrivono query con 200 e passa linee con profondità di query
nidificate a 3-4 livelli... jet si impalla scaricandomi l'intero db2 in
locale.
Finchè si tratta di prenderi una rubrica telefonica... va bene. Il resto
lasciamolo fare a DB2.
Del resto mi sembra di applicare l'approccio dei front-end degli ADP.
Fa fare il lavoro al server. Fagli fare ciò che serve (a patto di creare
query da 200 righe ;-)
Jet non dice sempre la verità al server, lo impegna anche in ciò che non
dovrebbe. Ripeto l'ho provato direttamente.
Del resto lo sapete tutti che Access è un desktop db. Per cui jet è frutto
di questa scelta.
A presto

 fino a prova contraria non si tocca.
Credo che l'ostinazione (anche un po infantile, a dire il vero ;-)) con la
quale ci stiamo ostinando a sostenere le nostre rispettive tesi, da qualche
parte abbia, sia da un lato che dall'altro, un fondamento sperimentato.
Nel caso specifico, credo che la differenza sostanziale la faccia il driver
ODBC.
Provo a fare un esempio. Se utilizzo i driver 2.51 di MyODBC, il
comportamento delle mie applicazioni degrada considerevolmente (rispetto ai
driver 3.51), poichè molte cose vengono computate localmente, con forte
aggravio del traffico di rete. La cosa, dunque, è coerente con quanto
riportato da OneEDP.
Ma quello che ci tengo a sostenere, è che tale anomalia _non_è_ di jet, ma
dell'implementazione dei driver odbc! Non è assolutamente vero che jet abbia
necessità di portare in locale i dati per lavorare con tabelle collegate
ODBC.
Tutto qui. ;-)
Ciao, Sandro.


 ha scritto nel messaggio
news:212Z210Z230Z116Y...@usenet.libero.it...

Molto brutalmente dovrebbe esistere un driver ODBC che "traduca"
correttamente tutte le richieste di Jet da inviare al server.
Il che è un miraggio.
In ogni caso il bello del NG è proprio questo. Portare il contributo sulla
base delle proprie esperienze... tanto c'è sempre da imparare.
Ciao
Daniele

 implementano in modo davvero molto raffinato.
Credo anch'io che dipenda dai drivers ODBC.
Quelli per MS SqlSvr funzionano (a patto che si evitino ingenuità "da
manuale") assai bene ... ma dubito che lo stesso discorso valga per tutti i
server di database.