Access, MySQL e settaggio ODBC
FabrizioAlba
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
Giuseppe Maxia
> 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?
Ci sono due spiegazioni possibili, e possibilmente entrambe responsabili
allo stesso tempo:
- quando hai migrato i dati da Access a MySQL non hai esportato chiavi primarie
e indici, per cui adesso le query vengono fatte tutte con un "full table scan".
- Se stai usando MySQL tramite access (come mi pare di capire dal link .mdb
che stai usando) le query vengono eseguite due volte: una volta da MySQL,
e una volta da Access.
Per il primo problema, controlla che ci siano gli indici adeguati, sia le chiavi
primarie sia gli indici sulle chiavi esterne.
Per il secondo problema, o eviti di usare Access come intermediario, oppure
devi trasformare tutte le query e fare in modo che siano "pass-through" (non
ho mai usato la versione italiana di Access e non so se vengono chiamate in
modo diverso), cioe' invece di essere rielaborate da Access (che per farlo
richiama dati dal server con migliaia di query orribilmente inefficienti)
vengono inviate al server direttamente.
> Grazie per le risposte
>
> Fabrizio
>
ciao
gmax
--
_ _ _ _
(_|| | |(_|><
_|
http://gmax.oltrelinux.com
Elfobianco
> Ci sono due spiegazioni possibili, e possibilmente entrambe responsabili
> allo stesso tempo:
>
> - quando hai migrato i dati da Access a MySQL non hai esportato chiavi
> primarie
> e indici, per cui adesso le query vengono fatte tutte con un "full
> table scan".
>
> - Se stai usando MySQL tramite access (come mi pare di capire dal link .mdb
> che stai usando) le query vengono eseguite due volte: una volta da MySQL,
> e una volta da Access.
>
> Per il primo problema, controlla che ci siano gli indici adeguati, sia
> le chiavi
> primarie sia gli indici sulle chiavi esterne.
>
> Per il secondo problema, o eviti di usare Access come intermediario, oppure
> devi trasformare tutte le query e fare in modo che siano "pass-through"
> (non
> ho mai usato la versione italiana di Access e non so se vengono chiamate in
> modo diverso), cioe' invece di essere rielaborate da Access (che per farlo
> richiama dati dal server con migliaia di query orribilmente inefficienti)
> vengono inviate al server direttamente.
>
>> Grazie per le risposte
>>
>> Fabrizio
>>
>
> ciao
> gmax
>
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
Giuseppe Maxia
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
FabrizioAlba
> > 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.
> >
> > collegamenti al database sql, e non delle queries.
> >
> > 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
> ciao
> 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?
Giuseppe Maxia
[...]
> 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.
Ed e' la parte che devi eliminare.
> Il mio dubbio a questo punto è che sia necessario
> rivedere un attimo il codice... Che dici???
Togli "un attimo" e credo sia l'attivita' giusta. :)
>
> Buona giornata, Fabrizio
>
> PS: una curiosità per quanto riguarda il cognome... sardo anche tu?
Dichiaratamente!
http://www.perlmonks.org/?node_id=127116
Sandro
> FabrizioAlba wrote:
> - Se stai usando MySQL tramite access (come mi pare di capire dal link
.mdb
> che stai usando) le query vengono eseguite due volte: una volta da MySQL,
> e una volta da Access.
[cut]
> Per il secondo problema, o eviti di usare Access come intermediario,
oppure
> devi trasformare tutte le query e fare in modo che siano "pass-through"
(non
> ho mai usato la versione italiana di Access e non so se vengono chiamate
in
> modo diverso), cioe' invece di essere rielaborate da Access (che per farlo
> richiama dati dal server con migliaia di query orribilmente inefficienti)
> vengono inviate al server direttamente.
>
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/
Giuseppe Maxia
> Il 13 Ott 2005, 18:03, Giuseppe Maxia <gmax_@_cpan_._org> ha scritto:
>
>>FabrizioAlba wrote:
>
>
>>- Se stai usando MySQL tramite access (come mi pare di capire dal link
>
> .mdb
>
>>che stai usando) le query vengono eseguite due volte: una volta da MySQL,
>>e una volta da Access.
>
>
> [cut]
>
>
>>Per il secondo problema, o eviti di usare Access come intermediario,
>
> oppure
>
>>devi trasformare tutte le query e fare in modo che siano "pass-through"
>
> (non
>
>>ho mai usato la versione italiana di Access e non so se vengono chiamate
>
> in
>
>>modo diverso), cioe' invece di essere rielaborate da Access (che per farlo
>>richiama dati dal server con migliaia di query orribilmente inefficienti)
>>vengono inviate al server direttamente.
>>
>
> Santo cielo quante cazzate ...
>
> Scusa. Hai mai usato Access e Mysql con MyODBC? Non dirmi di si 'che non ci
> 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.
Sandro
> > Scusa. Hai mai usato Access e Mysql con MyODBC? Non dirmi di si 'che non
ci
> > 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.
Amico mio. Sei saccente e superficiale al tempo stesso. La cosa è abbastanza
incompatibile con la professione dell'informatico.
Se metti la query di cui sopra in un *dynaset* di access avrai, come
giustamente osservi tu, una dozzina di query. Ma il motivo è presto
spiegato, e lo avresti capito anche tu se solo ti fossi fermato un attimo ad
analizzarlo il query log, piuttosto che contarne solo le righe ...
Il motivo è che i dynaset sono griglie con dati modificabili. Access le
gestisce facendo un pre-fetching dei bookmarks (tutto ciò che somiglia ad
una pk per le tabelle) e poi visualizza le colonne visibili (quelle nascoste
al di fuori del video no, tanto per intenderci ...) cercando i valori
attraverso i bookmark precedentemente trovati. Il vantaggio di tale
approccio è che queste griglie ti consentono la modificabilità dei dati
tanto sul lato uno che sul lato molti del join ... scusa se è poco ... con
tanto di lock (ottimistico) e gestione della modifica concorrente di un
campo da più sessioni. Lo svantaggio, indovina un po, è lo stress che Access
provoca facendo un sacco di query al database.
Prova ad utilizzare la stessa query con una *snapshot* ... prova ... prova
solo a cambiare il tipo di query.
E per cortesia, Jet utilizza il '*' come wild, non il '%' ... la conversione
dei wild te la fa il precompilatore jet prima di invocare i driver odbc.
Prova prova ... poi fammi sapere ...
Ah, dimenticavo, ho applicazioni da 20 milioni di record gestite, fra
l'altro, da client fatti con Access e MySQL come be. Figurati se
funzionerebbero se dovessero portarsi in locale i dati.
>
> 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.
Giuseppe Maxia
[SNIP]
>
> Amico mio. Sei saccente e superficiale al tempo stesso. La cosa è abbastanza
> incompatibile con la professione dell'informatico.
>
Non entro nel merito.
Puo' capitarmi di dire qualche castroneria, e sono felice di imparare qualcosa di nuovo
anche alla mia eta' non proprio verde. Ma mi da fastidio sentirmi dare dell'idiota
solo perche' ho proposto la soluzione A invece della soluzione B.
> Se metti la query di cui sopra in un *dynaset* di access avrai, come
> giustamente osservi tu, una dozzina di query. Ma il motivo è presto
> spiegato, e lo avresti capito anche tu se solo ti fossi fermato un attimo ad
> analizzarlo il query log, piuttosto che contarne solo le righe ...
>
> Il motivo è che i dynaset sono griglie con dati modificabili. Access le
> gestisce facendo un pre-fetching dei bookmarks (tutto ciò che somiglia ad
> una pk per le tabelle) e poi visualizza le colonne visibili (quelle nascoste
> al di fuori del video no, tanto per intenderci ...) cercando i valori
> attraverso i bookmark precedentemente trovati. Il vantaggio di tale
> approccio è che queste griglie ti consentono la modificabilità dei dati
> tanto sul lato uno che sul lato molti del join ... scusa se è poco ... con
> tanto di lock (ottimistico) e gestione della modifica concorrente di un
> campo da più sessioni. Lo svantaggio, indovina un po, è lo stress che Access
> provoca facendo un sacco di query al database.
>
> Prova ad utilizzare la stessa query con una *snapshot* ... prova ... prova
> solo a cambiare il tipo di query.
>
Ti e' sembrato che io abbia parlato di form? A me non pare.
Se fai l'esperimento che ho descritto con una query, il problema sussiste.
Effettivamente, usando gli snapshot, Access fa solo una query, ma ne fa una sola
anche quando, come dicevo io, imposti la query come "pass-through". A quel punto,
non c'e' bisogno di cambiare da dynaset a snapshot, perche' la query e' gia'
ottimizzata. La "pass-through" ha anche il vantaggio (sperimentato) di essere piu'
veloce delle query passate tramite il filtro di ODBC.
> E per cortesia, Jet utilizza il '*' come wild, non il '%' ... la conversione
> 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.
Sandro
> Sandro wrote:
> [SNIP]
>
> >
> > Amico mio. Sei saccente e superficiale al tempo stesso. La cosa è
abbastanza
> > incompatibile con la professione dell'informatico.
> >
>
> Non entro nel merito.
> Puo' capitarmi di dire qualche castroneria, e sono felice di imparare
qualcosa di nuovo
> anche alla mia eta' non proprio verde. Ma mi da fastidio sentirmi dare
dell'idiota
> solo perche' ho proposto la soluzione A invece della soluzione B.
Giuseppe, ti leggo da molto tempo su questo ng e so che sei un personaggio
molto molto preparato ... ma paradossalmente una cazzata detta da un
personaggio *di spessore* finisce per essere ancora più grossa che se detta
dal lamer di turno ... per questo ti ho invitato a non liquidare in modo
troppo superficiale la cosa.
Ti chiarisco che non c'è nulla di personale.
> Ti e' sembrato che io abbia parlato di form? A me non pare.
> Se fai l'esperimento che ho descritto con una query, il problema sussiste.
Direi che gli unici validi (anzi stravalidissimi) motivi per usare un fe
Access sono le form ed i report ... era ovvio ... oltre all'integrazione con
Office.
>
> Effettivamente, usando gli snapshot, Access fa solo una query, ma ne fa
una sola
> anche quando, come dicevo io, imposti la query come "pass-through". A quel
punto,
> non c'e' bisogno di cambiare da dynaset a snapshot, perche' la query e'
gia'
> ottimizzata. La "pass-through" ha anche il vantaggio (sperimentato) di
essere piu'
> veloce delle query passate tramite il filtro di ODBC.
Giuseppe. Ti devo bacchettare nuovamente. ;-)
Siamo daccordo che le query PT siano più efficienti. Il problema è che le
query pt sono nel dialetto sql del server. Nelle query normali jet, invece,
le query sono nell'sql di jet. Con alcuni intelligenti accorgimenti nell'uso
delle query jet ottieni il duplice effetto di avere una query largamente
ottimizzata lato be e l'uso dell'sql di jet, non quello del server.
Questo significa che l'applicazione non avrà (quasi) alcuna idea del be,
poichè poggerà sul layer jet. Io questa cosa non la sottovaluterei. Ho un
cliente che è partito con MySQL ed è finito ad Oracle, e sui fe non ho
cambiato praticamente nulla.
Mi sono spiegato?
>
> > E per cortesia, Jet utilizza il '*' come wild, non il '%' ... la
conversione
> > 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.
Non ho fatto l'integralista della sintassi. Te l'ho voluto far notare
proprio per ciò che ti dicevo sopra: una query "LIKE '*pippo*' " su jet
verrà tradotta da jet (e odbc) nelle convenzioni del be, nel caso di MySQL
con "LIKE '%pippo%'". Ma l'applicazione userà semre il wild di jet, il
remapping lo fa jet ed odbc.
> Cosa che dovrei continuare a fare, e tutto sommato e'
> 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.
Giuseppe Maxia
[SNIP]
> Giuseppe, ti leggo da molto tempo su questo ng e so che sei un personaggio
> molto molto preparato ... ma paradossalmente una cazzata detta da un
> dal lamer di turno ... per questo ti ho invitato a non liquidare in modo
> troppo superficiale la cosa.
>
>
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
Sandro
> 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.
Perchè c'è un'alternativa os ad access? Mi son perso qualcosa?
> 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.
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.
Giuseppe Maxia
[SNIP]
> 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.
Solo una precisazione. Non sono un sostenitore dell'open source ad occhi chiusi.
Dico che trovo le alternative piu' interessanti, dopo averle sperimentate.
Su Windows, le alternative opensource ad Access sono quasi inesistenti. Se
costretto, ripiego su Delphi. Se ho liberta' di scelta assoluta, consiglio
un'architettura che includa un application server (e fra Java, Perl, PHP, con
relativi ambienti CMS, la scelta e' vasta).
Per il resto, i "talebani" del free software ad ogni costo (e del free software
"riconosciuto dai profeti" contrapposto al free software non benedetto) danno fastidio
anche a me.
>
> E' stato un piacere confrontarsi.
Reciproco.
>
> Saluti, Sandro.
paolo...@gmail.com
> Dico che trovo le alternative piu' interessanti, dopo averle sperimentate.
> Su Windows, le alternative opensource ad Access sono quasi inesistenti.
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.
enoquick
>> Non sono un sostenitore dell'open source ad occhi chiusi.
>> Dico che trovo le alternative piu' interessanti, dopo averle sperimentate.
>> Su Windows, le alternative opensource ad Access sono quasi inesistenti.
Postgresql e Mysql (ancora meglio di access)
sqlite per un db leggerissimo
Non basta ?
Jack
esterni.
Ciao Jack
--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?
enoquick
> enoquick <enoq...@gmail.com> wrote:
>
>> Il 03/03/2014 08:16, paolo...@gmail.com ha scritto:
>>>> Non sono un sostenitore dell'open source ad occhi chiusi.
>>>> Dico che trovo le alternative piu' interessanti, dopo averle sperimentate.
>>>> 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
>
Infatti access è un db del cavolo :)
Jack
bisogno.