Newsgroup: it.comp.appl.access
Titolo: Access e Mysql ODBC

Salve a tutti. Ho convertirto un BE di access97 in mysql  utilizzando myodbc
3.51 . Successivamente nel mio db di access97 ho creato un  collegamento
tramite ODBC a queste tabelle convertite in mysql. Precisando che lavoro in
locale e non in rete, l'apertura delle tabelle è diventata incredibilmente
lenta!!!!! Tanto lenta che anche winamp procede a scatti durante l'apertura
delle tabelle!! Qualcuno sa dirmi il motivo?? Preciso che uso w98, a97,
myodbc 3.51, l'ultima versione di Mysql,p3650 con 256mb ram 40gb hard disk
con 10gb liberi. Il database originale di access97 è di circa 140mb
compressi in quanto contiene circa 600.000 record.
Grazie a tutti!!!!!
yuri


Direi che 600.000 record sono un buon motivo per non aprire in
visualizzazione foglio dati una tabella ODBC.
Ciao, Sandro.
--------------------------------
Inviato via 
http://usenet.libero.it

 ha scritto nel messaggio
news:tdrK9.12000$Ou4.3...@twister2.libero.it...

Credo che dovresti ottimizzare la GESTIONE RECORD...........!!
Sarà mai possibile che un'utente abbia la necessità di visualizzare
6000.000 RECODS................................!!!
I dati vanno reperiti solo se servono, quindi usa delle QRY_PassTROUGTH
eventualmente per recuperarli, sono in sola lettura, ma non lasciano
a JET l'interpretazione della Stringa SQL..........!!!
@Alex.

 ha scritto nel messaggio
news:1oBK9.13063$Ou4.4...@twister2.libero.it...

premettendo che di mysql non ci capisco niente, avevo pensato che
convertendo le tabelle del mio database in mysql avrei risolto i noti
problemi di affidabilità e lentezza di Jet (soprattutto in
access97)soprattutto dopo aver letto un articolo sul sito comune(in
particolare quello che spiega che access97 ogni tanto cancella record a
caso). Aggiungo che aprendo le stesse tabelle in access97 la velocità è
buona.
Che db potrei usare per risolvere questi problemi secondo voi??
Grazie
Yuri

 Che db potrei usare per risolvere questi problemi secondo voi??
Leggi i consigli di @Alex.
I tomi di programmazione Client-Server raccomandano di concepire il software
in modo che ai Clients  vengano restituiti al massimo poche centinaia di
records ... e tu ci parli di 600.000?
Ciao.

 a JET l'interpretazione della Stringa SQL..........!!!
Oltre a dargli in pasto a MySQL delle query pass-through potresti
anche settare dei LIMIT
select * from `nomedb`.`nometabella` limit 0,50;
Ciao,
Lo


il problema, non è il server db, è l'applicazione che accede ai dati...
se la progetti male, ogni volta che apri una maschera scarichi tutti i
record (che è un'idiozia, qualsiasi architettura usi, a meno di non avere 4
record...) e quindi l'applicazione è lentissima.
magari hai il server che si gratta, ma l'applicazione deve gestirsi tutti i
record tutte le volte che apri una maschera e quindi non va avanti.
mysql va benissimo, riscrivi le query delle maschere, magari trasformandole
in query passthrough, in modo che il client mandi la richiesta e poi riceva
solo i dati che vuole e non tutto quello che c'è sul server...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/2002

 a JET l'interpretazione della Stringa SQL..........!!!
Per quanto riguarda le maschere associate, che non potrebbero usare i
resultset di una query pass-thru, io mi sto orientando sulla soluzione che
applica un filtro "al volo" ad una maschera (magari sulla base di un valore
chiave preso da una combo), che apro in modalità "aggiunta dati". In tal
modo la maschera si apre facendo una add-new (e non si scarica un tubo dal
server) ed eventualmente scarica il solo record specificato dal filtro.
Ovviamente, ho tolto i pulsanto di scorrimento ...


 server) ed eventualmente scarica il solo record specificato dal filtro.
E' interessante, però potresti essere più chiaro?
Voglio dire: la modalità "aggiunta dati" non serve solo ad aggiungere nuovi
records?
Ciao.

 records?
All'apertura della maschera questa è in modalità "aggiunta". In pratica,
quando l'utente chiama la maschera, questa si apre pronta per inserire un
nuovo record. A meno che l'utente non voglia cercare un record esistente, da
un combo o da un qualsiasi strumento di ricerca. In tal caso, sull'evento
after_update della combo imposto:
me.filter="filtro_che_pesca_il_record"
me.filteron=TRUE
me.requery
e la maschera associata mi visualizza il record cercato.
L'odbc-monitor mi evidenzia che, all'atto della requery, viene sparato al db
la query:
select <dettagli_origine_dati>
where <filtro_che_pesca_il_record>
e quindi, di fatto, posso anche avere qualche milione di record ed una
maschera associata, tanto leggo solo il record che mi occorre visualizzare.
Se non sono stato chiaro, riposto. ;-)


 ha scritto nel messaggio
news:212Z210Z230Z100Y...@usenet.libero.it...

Premettendo il fatto che sono pochi mesi che uso access e quindi le query
pass trought non so cosa siano, in pratica la mia applicazione è lenta
perchè, usando delle query normali, esse scaricano tutto il contenuto del
database e poi la query viene eseguita????dove posso trovare della
documentazione sulle query pass-trought??
L'odbc monitor cos'è??
Grazie a tutti!
Yuri

 L'odbc monitor cos'è??
E' una modalità di utilizzo dei driver ODBC, che loggano tutto l'sql che
transita dai drivers verso il server.
Per attivarlo, consulta la documentazione allegata al driver MyODBC.


 Se non sono stato chiaro, riposto. ;-)
Sei stato chiarissimo e hai avuto un'idea grande ... direi da postare al
webmaster del sito comune.
Ciao.

 Se non sono stato chiaro, riposto. ;-)
L'ho appena provato e funziona bene.
Tuttavia non riesco a spiegare concettualmente come questo metodo possa
evitare (sempre e comunque) lo scaricamento dell'intero recordsets sul PC
locale: la stringa Filter viene composta con la sintassi SQL di Jet.
Non è che i filtri che hai provato fossero in corrispondenza di campi
indicizzati?
Ciao.

 indicizzati?
Assolutamente no. Ti dirò di più. Molte openforms sono fatte dall'interno di
altre maschere, con condizione di filtro "al volo" anche su chiave non
primaria.
Credo, ma ne so troppo poco di database per esserne certo, che tutto si
giochi nella eccellente simbiosi fra jet ed il driver MyODBC.
BTW, funzia alla grande.


 locale:
Per completezza, esistono dei casi in cui jet si porta in locale il
resultset:
1) funzioni di Access nelle query di origine (tipo ... WHERE
campo=miafunzione())
2) capabilities non supportate da MySQL (tipo select nidificate o query
pivot)
3) non coerenza fra gli indici esistenti sul server e quelli descritti
localmente (chessò, se aggiungi un indice sul server e poi non ti aggiorni
il collegamento, jet finisce per ignorare la presenza dell'indice,
sovvertendo in modo inaspettato la strategia di risoluzione di qualche query
con join)
Ma esistono anche casi in cui mi aspetterei che jet si portasse almeno
parzialmente una tabella in locale, ma la cosa non avviene, come, ad
esempio, se progetti una query che utilizza un'altra query. Jet fa alcune
assunzioni intelligenti, e quasi sempre riesce a risolvere queries di
queries attraverso un'unica query più complessa.


 con join)
Beh, ma a questo punto è tutto *da manuale* ODBC  ;-))
Ciao.