Newsgroup: it.comp.software.database
Titolo: Access, MySQL e settaggio ODBC

Buon pomeriggio a tutti.
Sul Pc ho installato MySQL Server 4.1 con tutti i tool utili (MySQL
Administrator 1.1, Quesry Browser 1.1 e Migration Toolkit 1.0), Access
2003 SP 1 e MySQL ODBC Driver 3.15.
Ho necessità di far lavorare con MySQL un programma scritto in VB e che
fino ad oggi lavora su DB Access. Per far questo ho creato un .mdb di link
tramite access utilizzando ODBC. Fin qua tutto bene: il programma funziona.
Il problema è che è veramente molto molto lento... peggio che con Access.
Premesso che deve tirar fuori query anche con 200.000 righe, e che tramite
MySQL Query Browser le fa senza problemi in un lampo, vorrei capire dove
sta il problema. 
Le uniche impostazioni di ODBC che ho flaggato sono "Don't optimize Column
Width" e "Return matching rows".
A questo punto mi viene da pensare che il collo di bottiglia avvenga
nell'ODBC. Secondo voi cosa potrei fare per renderlo più veloce?
Grazie per le risposte
Fabrizio
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
ciao
gmax
-- 
  _  _ _  _
(_|| | |(_|><
  _|
http://gmax.oltrelinux.com

 
Ciao e innanzi tutto grazie per la risposta...
In effetti una delle tabelle dell'mdb originale non č indicizzata, ma 
nella procedura di migrazione con il toolkit questa cosa non mi da 
nessun problema. Quando vado a fare il link al database sql da access me 
la segnala ma risolvo il problema selezionando uno dei campi in modo da 
indicizzarlo.
Per quanto riguarda le pass-through sinceramente non ho la piů pallida 
idea di come farle, visto che il file mdb in cui ho fatto il link ha dei 
collegamenti al database sql, e non delle queries.
Qualunque suggerimento o consiglio č estremamente gradito.
Fabrizio


Guarda, questo lo so per esperienza diretta, documentato abilitando il log
del server che stavo usando. Se usi Access come intermediario,
ogni volta che fai una query con un join, Access chiede al server tutti i record
di tutte le tabelle coinvolte, nell'intervallo richiesto, fa il join in locale,
e restituisce il risultato. Quindi una query che normalmente restituirebbe
10 righe, se proviene da una tabella di 200.000 record, rischia di avere un
traffico di decine di migliaia di record prima di produrre un risultato.
Se non sai come fare le query pass-through, ti consiglio di togliere di mezzo
l'intermedirio Access e fare le query direttamente dalla tua applicazione, usando
o il connettore .NET o ODBC.
connector/NET:   
http://dev.mysql.com/downloads/connector/net/1.0.html
come si usa:     
http://dev.mysql.com/doc/refman/5.0/en/connector-net.html
odbc:            
http://dev.mysql.com/downloads/connector/odbc/3.51.html


 gmax
Ho giù installato l'ODBC, la versione 3.51.11; la connessione dall'ODBC a
MySQL viene eseguita correttamente. Poi ho creato un mdb a cui ho
collegato le tabelle del DB MySQL. L'applicativo richiama l'mdb per
l'interrogazione del DB. Il mio dubbio a questo punto è che sia necessario
rivedere un attimo il codice... Che dici???
Buona giornata, Fabrizio
PS: una curiosità per quanto riguarda il cognome... sardo anche tu?


 PS: una curiosità per quanto riguarda il cognome... sardo anche tu?
Dichiaratamente!
http://www.perlmonks.org/?node_id=127116



Santo cielo quante cazzate ...
Scusa. Hai mai usato Access e Mysql con MyODBC? Non dirmi di si 'che non ci
credo proprio.
Ciao, Sandro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 credo proprio.
Ho l'impressione che TU non ci abbia mai provato.
Fai questa prova: abilita il general log di MySQL (quello che registra tutte le query,
non solo le modifiche). Poi fai un link da Access a due tabelle di MySQL.
Quindi esegui una semplice query con un join fra le due tabelle
(
per esempio, usando una tabella libri e una tabella autori:
     SELECT autore, titolo from libri
     INNER JOIN autori ON (libri.id_autore=autori.id_autore)
     WHERE titolo like "a%"
)
Se guardi il log, vedrai che al DBMS non e' arrivata una sola query, ma una dozzina.
Se invece non ti sei mai curato di vedere questi dettagli, puoi restare nella
tua beata inconsapevolezza. Ma evita di commentare in modo negativo chi sta
cercando di aiutarti.



Lascia perdere. Faccio questa professione come consulente e come accademico
da troppi anni ... l'inconsapevolezza, per me, è l'alimento primo dello
studio e del miglioramento professionale e culturale.
Il problema è di chi, come te, si è convinto di essere consapevole, e perde
di vista tante altre cosette interessanti.
Saluti.


 dei wild te la fa il precompilatore jet prima di invocare i driver odbc.
Quando uno usa vari DB, puo' succedere di sbagliare un carattere. E citavo a memoria,
non avevo Windows sottomano. Cosa che dovrei continuare a fare, e tutto sommato e'
meglio che lascio che chi ha problemi con Access se li risolva da solo.


 meglio che lascio che chi ha problemi con Access se li risolva da solo.
E fai male. Perchè mi convinco sempre più che i guru dei database
sottovalutino le possibilità di Access com RAD e FE a database veri e
prestazionalmente accettabili. E tu, che sei un grosso esperto di MySQL,
forse non ti sei mai soffermato a pensare che Access può essere utilizzato
(con successo) come framework di accesso a dati su MySQL, con tempi di
sviluppo irrisori, costi di test nulli, e performance (con un attimo di
attento uso degli strumenti di accesso ai dati odbc) assolutamente
rispettabili.
Io, per esempio, ho un paio di grosse applicazioni sviluppate con 
asp.net
 e
MySQL come be. E' vero che tutta la parte di accesso ai dati è
ottimizzatissima, con estensivo uso di strutture dialettali tipiche di
MySQL. E' però anche vero che l'applicazione ha un peso sul server web, e
quello che guadagno nell'accesso diretto ai dati lo perdo nei tempi del
webserver. In molti casi i be con Access sono, complessivamente, più veloci,
e mi forniscono una completissima integrazione desktop (esportazioni su
fogli elettronici, invio di mail con allegati i report, e tanti tanti altri
effetti scenici che ai miei clienti piacciono tanto ed ai quali non
rinuncerebbero mai ...).
Ciao, Sandro.


 
Ok.
Come ho detto prima, sono sempre pronto a imparare qualcosa.
E so anche imparare dagli errori. Apprezzo una discussione pacata e logica.
Ti ringrazio per le informazioni valide e utili.
[SNIP]
Io ho avuto una lunga esperienza con Access, che ho valutato a lungo prima
di buttarlo via. Ammetto di odiarlo abbastanza, (anche perche' l'ho dovuto
usare per forze con applicazini fatte da altri) e di apprezzare molto di piu'
le alternative open source. Per questo, le mie esperienze con Access si sono
arrestate qualche anno fa, e non ho nessuna intenzione di riprendere.
Se sono proprio costretto a sviluppare in Windows, scelgo Delphi.
Ciao


 Se sono proprio costretto a sviluppare in Windows, scelgo Delphi.
Chiarito che non sono un sostenitore di Microsoft o dell'open source, ma mi
ritengo abbastanza intelligente da scegliere lo strumento più adeguato
all'ambito di applicazione ...
ci tengo a precisare che, benchè mi affascini moltissimo l'os (tutti i miei
server installati hanno Linux e Mysql, e fanno firewall con iptables, e
cache server con squid...) trovo che sia anche intelligente ammettere che il
mondo MS ha dalla sua un set di prodotti che l'os ad oggi non può neanche
sognarsi ...
E Access è uno di questi, un prodotto maturo, che già da tempo ha
abbandonato l'idea di essere un rdbms (ammesso che mai lo sia stato) in
favore di un mero strumento di interfaccia ai dati (ed il fatto che msde sia
gratuito ne è la prova).
E' un peccato che l'open source abbia un atteggiamento *integralista* nei
confronti del sw closed. Ed è un peccato che tale atteggiamento integralista
condizioni le risposte date in un ng pubblico come questo.
E' stato un piacere confrontarsi.
Saluti, Sandro.


 Saluti, Sandro.


 Su Windows, le alternative opensource ad Access sono quasi inesistenti.
 
Francamente non ho trovato nulla di equivalente neppure su Linux (purtroppo), per carità non è che riprovo tutte le alternative tutti i giorni.
Lo ritengo un prodotto RAD notevole e lo sto usando dalla lontana versione 1.0 (quando la gran parte ha cominciato a usarlo dalla 2).
 
Ci sono tante 'menate che fanno incazzare'.
Ad esempio che la versione 2013 vada solo su Win7 w Win 8 (e infatti se la tengono).
L'ODBC di Windows 8 collegato in TCP/IP con SQL Server ha prestazioni imbarazzanti, devo ancora capire come venirne fuori (forse lavorando con l'eseguibile a 64 bit, ma ora non posso farlo, gli utenti hanno tutti Office a 32 o quasi).
 
In passaggio da 2003 a 2010 su database condivisi ha rallentato mostruosamente tutto. 
Insomma non sono tutte rose e fiori.

> Su Windows, le alternative opensource ad Access sono quasi inesistenti.
 
[CUT]
 
 
Postgresql e Mysql (ancora meglio di access)
sqlite per un db leggerissimo
 
Non basta ?
 


non sono proprio la stessa cosa. Per creare una GUI deci usare strumenti
esterni.
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?


 
Ma un vero database non ha una gui
Infatti access è un db del cavolo :)
 
 


un vero database e' quello che ti permette di fare il lavoro di cui hai
bisogno.
