Newsgroup: it.comp.software.database
Titolo: MySQL ODBC e Access97

Salve a tutti,
ho importato in MySql alcune tabelle da un DB Access97. La tabella più
grossa ha 600.000 righe.
Ho interfacciato MySQL ad Access via ODBC (2.50.39) e quando da Access
collego le tabelle e apro la tabella grosso ci mette quasi 5 secondi
prima di ridarmi il controllo dell'applicazione.
Inoltre se anche non tocco access noto che l'impiego della CPU rimane
fissa oltre il 60%...
Se invece apro la stessa tabella che risiedeva su Access l'apertura
era istantanea.
Insomma mi sembra molto lento tramite ODBC... c'è qualche accorgimento
che non ho usato?
PS Ho cercato su Google e non ho trovato nulla al riguardo se non
disabilitare il logging di ODBC ma non ho capito come fare.
Grazie
-- 
Per una pera, una pera cazzo...

 ha scritto nel messaggio
news:ov3e2vknb1irks2qu...@4ax.com...

I DRIVER ODBC di MYSQL fanno schifo.......!!
Prova con OLEDB e ADO sempre tu abbia A2K o AXP altrimenti è veramente
una pena, ho avuto lo stesso problema, non risolto.
L'alternativa è usare le API di MySQL, ma non ho avuto molto tempo per
provare
tutto.....!
@Alex.

una pena, ho avuto lo stesso problema, non risolto.
Cosa intendi?
OK aprire una connessione tramite VBA, ma se voglio aprire una
maschera su una tabella, come posso usare ADO?




Prova a disabilitare il "Tracing" da "ODBC Data Source Administrator"
.
Elisa

 che non ho usato?
Secondo me cinque secondi per aprire un recordset di 600.000 records con
ODBC sono buone prestazioni.
Ciao.

 che non ho usato?
I driver odbc 2.5X sono abbastanza buoni, ma non al livello dei 3.5,
eccellenti sotto ogni punto di vista. Veloci, affidabili, non mi hanno
ancora creato alcun problema (sgrat sgrat ...)
Quando l'applicazione è client-server è abbastanza improprio aprire in
modalità foglio dato una tabella di seicentomila records. Fatti delle query
con recordset modificabile, che restringano in modo opportuno la cardinalità
del recordset. Lo stesso effetto lo avresti se ti connettessi ad un provider
OleDB, perchè l'apertura della tabella in modalità foglio dato effettua, di
fatto, una "SELECT * FROM tabella".
Con questo accorgimento Access e MySQL tirano fuori applicazioni semplici,
affidabili e performanti. Questo, almeno, per quello che mi è dato di
sperimentare giornalmente.
Ciao, Sandro.
--------------------------------
Inviato via 
http://usenet.libero.it

 c'entra con MySQL.
Ecco il link
http://support.microsoft.com/default.aspx?scid=kb;en-us;160819

 tutto.....!
E come credi che siano stati scritti i driver ODBC?


 modalità foglio dato una tabella di seicentomila records. 
Io mi trovo spesso a dove accodare sulla tabella da 4.5M, l'accodamento il 
piu' delle volte si blocca. Settaggio: tutti i checkbox di Myodbc 
deselezionati. 
Ciao

del recordset.
Ok, capisco perfettamente il discorso...
Quello che però mi trovo a notare è che access97 apre la tabella
istantaneamente mentre se la linko tramite ODBC i tempi si allungano
fino a 5 o 6 secondi... e anche altre query mi sembrano più lente...
Il fatto è questo: io voglio portare la base di dati su MySQL però in
effetti mi sembra per le performance siano minori... e non riesco a
capire come mai dato leggo gran bene di questo prodotto...
oltretutto l'ho già provato per altri progetti e sono certo della sua
robustezza...


10 Mb).
Come hai stimato quel tempo esattamente?
Io uso MySQL 3.23 su un P4 1.5Gz 1Gb RAM e sulla stessa macchina via
ODBC linko le tabelle su A97...
Questa č la macchina che uso per sviluppare, il server sul quale
pensavo di mettere il tutto č piů piccolino... devo pensare che le
performance scenderanno?


E ti sembra troppo?
Scusa... aggiungo una considerazione al mio post di prima!
Quindi in poche parole Access gestisce l'apertura del recordset in
modo particolare?
Quello che non mi spiego è come faccia ad essere istantaneo ad aprire
il recordset...
Inoltre ho notato che tramite la console mysql esegue le query in
tempi brevissimi, mentre se uso ad esempio DBTools il tempo riportato
è di 0.2 secondi mentre prima di visualizzare la griglia con i dati
passano anche 3 o 4 secondi...


 performance scenderanno?
Si', io mi sono abituato a fare l'inverso, solitamente sviluppo su sistemi 
meno potenti di quelli finali.
ciao

Con uno Zenith el Primero :-)
:)
Ma il fatto è che in A97 l'apertura è istantanea...
e non me lo spiego...


 e non me lo spiego...
Sarà istantanea in monoutenza!
Devi ascoltare il consiglio di chi ti dice: "inutile far passare vagonate di
records attraverso una rete e cronometrare quale motore e relativo ODBC sia
più bravo ... preoccupati d'impostare il FE in modo che i records restituiti
dal Server siano pochi".
Ciao.

 passano anche 3 o 4 secondi...
Dunque. Secondo me i raffronti andrebbero fatti *solo* ed *esclusivamente*
su query. Fatti una query sulla griglia QBE di Access, copia e incolla la
query (mutatis mutandis) su un tool che non usi Jet (anche una query
pass-thru per esempio) e stima la differenza di performance.
Senza ricorrere alla query pass-thru il motore jet interpreta la query e la
passa (piů o meno rivisitata e corretta) al driver odbc. Salvo casi
abbastanza ben circoscrivibili, la traduzione che viene fatta (con i driver
ODBC 3.51, almeno) č uno-a-uno, per le query di selezione. Anche i tempi
sono sostanzialmente i medesimi.
Con i driver ODBC 2.5 la cosa cambia un po, essendo un po meno ampio il
catalogo delle capabilities ODBC supportate (il che obbliga spesso e
volentieri il motore Jet a portarsi blocchi considerevoli di record in
locale per elaborarseli).


 deselezionati.
Ok. Aggiornamenti e accodamenti si comportano in modo differente dalle
selezioni. Le query di aggiornamento vengono risolte da Jet portandosi il
recordset da modificare in locale. La cosa è visibile facendo attenzione
alla progress bar in basso a destra, che si attiva quando la query è risolta
localmente, ma che non si attiva nel caso in cui sia il server ad elaborarla
(cioè nella maggior parte delle query di selezione).
Io, per le query di aggiornamento/accodamento significativamente pesanti,
vado su pass-thru.


 Ciao, Sandro.
Non ho provato con A2K,  ma VB puň bastare...??
Probabilmente hai ragione i Driver ODBC si appoggiano alle API,
ma siccome mi hai incuriosito ho provato ad accedere ad una Tabella
estraendo una QRY con ODBC Direct e tramite API su 200.000 Records!
Estrazione effettuata su campo indicizzato.....!
API batte ODBC 3--1
Di piů non sň.....!
@Alex.

 ha scritto nel messaggio
news:d4XV9.15598$ZE.4...@twister2.libero.it...

Parole SANTE quelle di Max....!
In ogni caso JET è ottimizzato per ACCESS, e in effetti in Monoutenza
non ci sono paragoni......!
Il confronto andrebbe fatto in Rete in multiutenza......!
Possibilmente per dati in sola lettura usa Qry PassTrought, già così i tempi
si accorciano,
oltretutto la sola struttura del DB con Indicizzazioni mirate ti aiutano a
risparmiare moltissimo
tempo........!
@Alex.

 API batte ODBC 3--1
Una selezione su campo con indice e 200 mila records, su una macchina di
piccole dimensioni, viene risolta in meno di mezzo secondo. In che modo hai
fatto questa prova?
La cosa mi incuriosisce, perchè non me la spiego, visto che il driver chiama
le stesse api.


 alla progress bar 
Io una query A97 che crea una "tabella locale differenze" fra una tabella 
sorgente (pure locale) e la tabella mysql con i 4.500.000. Durante tale 
query la barra progressione di access sta ferma un tempo lunghissimo sulla 
prima tacca, e se guardo i task mi dice che access e' bloccato. Se ignoro 
l'avviso e lo lascio andare, alla fine lui conclude la query e mi scrive la 
tabella differenze.
Quando in un secondo tempo vado ad accodare tale tabella differenze alla 
mega tabella mysql, l'accodamento e' estremamente rapido.
ciao
B.


Database MySQL con 200.000 Rec ho eseguito una Qry PassTrought.(Tanto per
non intromettere troppo JET)........ ;-)
 tramite DAO con ODBC Direct in AXP ed ho popolato una Form,
l'interrogazione l'ho eseguita
su campo indicizzato.
Stessa cosa ho fatto con VB e le API di MySQL, solo che ho popolato
una FlexGrid.
Non intendevo con 3-1 il rapporto di miglioramento, ma con AXP circa 1.2
sec.
mentre con VB 0.86 sec.
Il tutto eseguito in locale ovvio che la QRY era la stessa.............!!!
@Alex.

 del motore Jet non gli frega nulla......!!!!!
D'accordo, ma con un .ADP non t'interfacci a MySQL.
O meglio, potresti lavorando di codice solo con oggetti .Connection (previa
verifica che il provider OleDB fornito con mysql garantisca l'aggiornabilità
delle Form di un .ADP).
Ciao.

 ha scritto nel messaggio
news:WLhX9.31448$YG2.8...@twister1.libero.it...

Era riferito all'utilizzo di DAO, in quanto non è scontato interporre JET
sempre e ovunque....!
In ogni caso puoi usare anche le API di MySQL, senza toccare ADO DAO OleDB o
ODBC ecc...........!!!!
In merito a questo ho valutato una risposta + rapida alla selezione come
descritto......!!!
Ciao.
@Alex.

 descritto......!!!
La cosa è interessante, però non credo si possa far tutto in "puro Access"
con le API di MySQL.
Cioè, con le API puoi popolare oggetti Combo o Report?
Ciao.

 wrote in message
news:StsX9.32261$
ZE.9...@twister2.libero.it

Non è scontato usare ODBC, c'è anche Oledb, ma meglio ancora API.
Con le API fai quello che vuoi, inquesto caso lancio la Stringa SQL
e mi ritorna un Recordset, che è esattamente quello che mi serve
senza usare ODBC o OleDB o xxxxxx.......! e, con AXP popolo già
tutti i controlli Bound.....!
Lo fai con puro VBA non c'è trucco non c'è inganno.... GIURO..!
Ciao.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Lo fai con puro VBA non c'è trucco non c'è inganno.... GIURO..!
E con i reports?
Ciao.

 ha scritto nel messaggio
news:DIvX9.33327$YG2.9...@twister1.libero.it...

Con VB hai Cristal Report, con AXP i Report non sono Bound..???
@Alex.

 Con VB hai Cristal Report, con AXP i Report non sono Bound..???
Sono Bound solo se utilizzi un .ADP (e quindi Recordset ADO).
Vabbè, diciamo che lavorando con un .mdb si potrebbe creare una gestione
mista MyODBC (tabelle collegate solo per reportistica che è meno importante)
e API per la gestione Forms.
Ciao.

 Con VB hai Cristal Report
Dimenticavo, Crystal Report viene usato come "accrocchio" _DataReport non ha
mai avuto grande successo_ dai VBisti, ma è un prodotto indipendente che
puoi usare pure con Access se ti va.

 wrote in message
news:fsNX9.36353$
YG2.1...@twister1.libero.it

Si, certo, ma Data Environment mi ha fatto impazzire....!!!
Ho preferito utilizzare una Classe per gestire l'oggetto printer
e mi sono trovato benissimo...., come le API di MySQL...!
@Aelex.


 Grazie


 entusiasmante!!!
Imho, hai colto il punto reale della questione. Che senso ha, per un client
(non per forza Access) metterti a display svariate decine di migliaia di
record?
Onestamente non riesco ad immaginare, ma potrebbe essere un mio limite,
l'utilità di spippolare un recordset che contiene un numero elevatissimo di
record. O, per lo meno, fino ad oggi non ho mai impattato con recordset
dalla cardinalità ingestibile, pur lavorando su applicazioni Access-MySQL
con circa sei milioni di record.



Sapessi quanto hai ragione.....!
C'è chi ama farsi del male.......... ;-)
@Alex.

 record?
A me capita di doverlo fare in sede di sviluppo / debug per rendermi conto
di come sono i dati.
Ha il vantaggio che oltre a mostrarmi cio' che mi aspetto, mi mostra anche
cio' che non mi aspetto.
Ciao
B.