Newsgroup: it.comp.appl.access
Titolo: Re: driver odbc molto lento

 ha scritto nel messaggio 
news:30900dca-0b18-4d92...@googlegroups.com...
Ciao,
sto usando un server LAMP su gui gira Mysql con tabelle InnoDB, a cui si 
connettono client realizzati con Access 2003 usando MyODBC-connector 5.1 su 
file DSN.
La mia lan č molto veloce e il ping verso il server č di pochi millisecondi, 
eppure le query dei client impiegano diversi secondi per dare un risultato.
Ho provato ad aggiungere su my.cong la stringa "skip-name resolve" ma senza 
effetti.
Qualcuno di voi ha avuto esperienze simili? come avete risolto?
C'č un driver piů veloce ed efficiente?
Grazie per l'aiuto
Saluti
Remigio
----------------------------------------
 
Per dare un parere sensato, sarebbe utile capire com'e' la query incriminata 
e come sono gli indici sulle tabelle coinvolte
Hai provato con i db-manager di MySql se la stessa query ci mette lo stesso 
tempo?
Giusto per capire se e' la query lenta oppure se e' il driver odbc 
 
 

 Giusto per capire se e' la query lenta oppure se e' il driver odbc
 
Ciao Roberto,
la lentezza si manifesta soprattutto nella query che popola una combobox ed una subform, niente di speciale, la combo mostra il contenuto dell'anagrafica utenti, mentre la subform l'elenco delle richieste pervenute per l'utente corrente.
IL mio sistema è situato su una intranet, nella mia sede (diciamo in "locale") funziona tutto abbastanza bene, mentre da un'altra sede remota, a parità di configurazione, il tutto si rallenta di brutto. Premetto che se faccio ping verso il server la risposta è molto rapida e la intranet è  davvero veloce, non credo ci siano colli di bottiglia o altra roba simile, a  occhio credo dipenda da odbc.
Sto pensando, siccome le tabelle sono InnoDB, devo provare a commutarle in MyIsam, forse si migliorerà qualcosa.
Altrimenti c'è un altro driver migliore?
Grazie molte e saluti
 
Remigio

 ha scritto nel messaggio 
news:47f7c771-e045-4518...@googlegroups.com...

-------------------------------------
 
Porta pazienza, ma 'ad occhio' non vuol dire un bel niente
Hai provato a vedere quanta 'roba' viene su dalla rete quando lanci la 
query?
Kilobyte ? Megabyte? Giga?
Il volume di dati ricevuti e' ragionevole con quello che intendevi avere?
Oppure arrivano dieci mega di roba e magari nella combo ci sono venti righe 
da 30 caratteri l'una?
Ma soprattutto, hai provato con in vari db-manager per MySql a fare la 
stessa query?
Risultati?
 
 
 

 Risultati?
 
No, non ho mai usato questi strumenti, non è che sono proprio un esperto in materia. Sto leggendo ora su internet che il problema potrebbe essere proprio quello che dici tu, ovvero che Access va a caricare le intere tabelle per poi eseguire la query e questo porta via tempo e risorse. 
Leggo che si potrebbero usare le query pass-trough.
Ti chiedo quindi due cose:
- indicami per favore un db manager che può fare al caso mio, proverò ad usarlo domattina;
- si possono convertire le query esistenti (e molte) in query pt?
Grazie a te Roberto per la pazienza e la bontà d'animo.
Un saluto.
 
Remigio

 ha scritto nel messaggio 
news:478853bd-b096-43f2...@googlegroups.com...

-----------------------------
 
http://www.databasejournal.com/features/mysql/article.php/3880961/Top-10-MySQL-GUI-Tools.htm
 
 
Sicuramente, per sfruttare le potenzialita' del server db, DEVI usare le 
query pass-trough
Se si possano convertire senza modifiche, nin-zo
Prova, e poi pubblica le esperienze
Ma quanto e' grosso l'intero db?
E a quanto viaggia la rete (che mi pare di capire sia una rete geografica) ? 
 
 

 E a quanto viaggia la rete (che mi pare di capire sia una rete geografica) ?
 
il db è di soli 50 MB.
Ho cercato di togliere alcune query all'apertura della form principale ma il risultato non è cambiato di molto.
Con phpmyadmin vedo che nella process list c'è scritto "writing to net"
La wan è a 2Mbit, per le altre applicaizoni va benone, questa si impalla.
Ho provato a convertire una query con diverse tabelle e relazioni ma la sintassi finale risulta sbagliata, per esempio c'è un riferimento ad un controllo della form del tipo Forsm!Utenti!data_nascita che non so convertire.
Quale strumento mi consigli per analizzare ciò che avviene all'interno del server?
Grazie per l'aiuto
un saluto
 
Remigio

 ha scritto nel messaggio 
news:36e5a3f8-24dc-446e...@googlegroups.com...

---------------------------------------------------------------
 
Sta benedetta query, se lanciata da un qualche db-manager installato su un 
client, ci mette lo stesso tanto tempo oppure no?
In rete passano 200 Kbyte o 50 Mbyte?
 
 
 

 In rete passano 200 Kbyte o 50 Mbyte?
 
Ho provato ad eseguire direttamente la query più impegnativa, quella con molte relazioni tra tabelle, e ci ha messo praticamente lo stesso tempo.
Dalle informazioni di runtime di phpmyadmin vedo che i dati
ricevuti sono circa 350 kB
inviati circa 17MB
Grazie
 

 ha scritto nel messaggio 
news:30837115-f0c5-4069...@googlegroups.com...

--------------------------------------------
 
Ma possono davvero essere 17 MB i dati restituiti dalla query?
No perche' 17 MB/sec / 0,2 MB/sec (velocita della rete) = 85 secondi, e' 
normale
O la query e' sbagliata e tira su tanta roba che non serve oppure la query 
restituisce un volume di dati che non ti aspettavi, nel senso che se hai una 
tabella con 1000 clienti e fai 'select * from CLIENTI'  e' normale che ti 
arrivino addosso tutte le colonne di tutti i 1000 clienti nel db
Hai un'idea, anche approssimativa, di quanta roba dovrebbe venir su ?
 
 


 
 
La cosa non è "automatica", se possibile i drivers ODBC eseguono le query 
lato Server.
Per capire quando non è possibile ti può aiutare questo whitepaper:
 
http://support.microsoft.com/kb/128385/EN-US
 
 
Saluti.
 
 

 Saluti.
 
Ho provato a definire meglio le query nelle maschere e eliminare quello che non serve, pare che va molto meglio, però c'è sempre una lentezza evidente, soprattutto all'avvio, in fase di login e in fase di caricamento deila prima select.
Sto cercando di capire dove possono esserci altri problemi.
Grazie per l'interessamento Roberto, sei gentile.
Un saluto.
 
Remigio