Newsgroup: it.comp.lang.visual-basic
Titolo: Passaggio da Access a MySql.

Salve a tutti, volevo chiedervi un informazione. Ho dei DB in Access che
vorrei in un prossimo futuro trasformare e gestire in MySQL e PHP. Si
tratterebbe di riscriverli completamente e comunque solo dopo aver studiato
a fondo i 2 nuovi sistemi. Per ora mi chiedevo una cosa, nel frattempo
sarebbe possibile creare un ibrido tra MySQL ed Access? Mi spiego meglio,
visto che le maschere, i report e tutta la programmazione per ora va bene
così com'è, nel frattempo la mia intenzione era trasferire le tabelle su
MySQL. Sia per problemi di stabilità di Access (più di una volta in chiusura
ho avuto degli errori strani che mi hanno danneggiato l'intero DB ed addio
ai dati), sia per problemi di protezione che di uso in rete dei database.
Normalmente per l'aggiornamento dei dati in tabella o per qualsiasi
operazione su di esse, mi avvalgo delle DAO. Dichiaro quindi il DB come
DAO.DATABASE e le relative tabelle come DAO.RECORDSET. Magari ci sono anche
modi migliori ma io da quando ho cominciato a lavorare con Access mi sono
trovato benissimo così e non ho mai incotrato la necessità di cambiare. Se
quindi in qualche modo potessi indirizzare come DB quello di MySQL che
contiene le tabelle, in teoria potrei continuare ad usare quei recordset
così come sono, ma esiste questa possibilità? Ed in caso non potessi
continuare ad usare le DAO, in che modo potrei applicare quanto descritto
senza dover stravolgere completamente il codice delle varie maschere?
Grazie mille per l'attenzione.
Ciao, Ciao.

so che in mysql si possono importare i fati da dei file, per cui se
riesci ad esportare i dati in file di testo separando i campi con "|"
poi puoi reimportarli in mysql, esempio 
|campo1|campo2|campo3|campo4

 ha scritto nel messaggio
news:1137503624.4...@g47g2000cwa.googlegroups.com...

Ti ringrazio per l'interessamento. Diciamo che il problema principale non
era tanto l'esportare le tabelle fisicamente, ho dato per scontato che
questo fosse possibile, mi pare anche di aver visto qualche utility in grado
di farlo. Il problema era per maschere e report che non so come potrebbero
essere agganciate alle tabelle presenti su MySQL invece che interne al db
stesso. In più visto che le operazioni sulle tabelle fatte dalle maschere
del db avvengono tutte da codice Visual Basic e tramite l'uso delle DAO, non
so se basterebbe modificare solo un minimo di codice affinchè queste
maschere possano puntare le tabelle anche se esterne al db, o meglio in
MySQL.
Grazie mille ancora.
Ciao, Ciao.

Ciao,
anche io ho un progetto VB6 che utilizza estensivamente DAO e fin'ora
ho sempre utilizzato database in formato Jet 4.0.
Ovviamente la stabilita' del database e' sempre un grosso problema e
nel tempo ho provato praticamente tutti i database alternativi che mi
sono capitati sotto mano (MSDE, Sql Server, MySQL 4.1 e 5.0, ecc.)
Se non vuoi riscrivere tutto il programma e passare ad ADO allora il
database server che a mio avviso funziona meglio (soprattutto a livello
di performance) e' MySQL. Aggiustando la stringa di connessione al
database e qualcosina sulle query vedrai che riuscirai a migrare
l'applicativo su MySQL in tempi abbastanza brevi. L'unica cosa a cui
devi prepararti e' un sensibile calo di prestazioni. Ho fatto una marea
di esperimenti ma a quanto pare l'abbinamento DAO/Jet e' imbattibile in
termini di performance (almeno se parliamo di database con tabelle che
non contengono decine di migliaia di record).
Probabilmente il collo di bottiglia sta nel dover passare tramite il
driver ODBC  :-(

 passare tramite il driver ODBC  :-(
Ti smentisco nuovamente =)
Esiste il driver VBMySQLDirect che ha un modello a
oggetti identico ad ADO (e pertanto e' estremamente
facile un porting) e che lavora direttamente con il
motore di MySQL, con prestazioni 4-5 volte piu'
elevate del corrispondente ODBC. Unica pecca e'
che ancora non supporta le Stored Procedures.
hth,
Lokar 

 che ancora non supporta le Stored Procedures.
Secondo me stavano parlando di *non* passare ad Ado (o al tuo Ado 
tamarro), ma di usare Dao su Odbc (non mi esprimo perchè non l'ho mai 
fatto).
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 su Odbc (non mi esprimo perchè non l'ho mai fatto).
Ho riletto il post di Myno ed effettivamente avevo
interpretato "Se non vuoi riscrivere tutto il programma
e passare ad ADO" come un suggerimento a passare ad ADO
per non riscrivere tutto (la qual cosa, in effeti, ha
poco senso).
Relativamente all'ADO tamarro, ovviamente mi vien da
sorridere, pero' vorrei fare una puntualizzazione.
Chi ha scritto VBMySQLDirect, ha incapsulato i metodi
delle API di MySQL per Windows in una DLL.
Ora, siccome il vantaggio e' notevole in termini di
prestazioni, e quale che sia il modello usato (DAO+JET,
ADO, ODBC) non ha molto senso parlare di "portabilita'"
in VB, un'interfaccia vale l'altra. Nella fattispecie,
cosi' come esistono numerose "comode" e performanti
interfacce su Winsock, che usano le DLL di Windows,
piuttosto che il componente "schifido" messo a
disposizione da VB, cosi' VBMySQLDirect sfrutta le
API proprie del motore MySQL, piuttosto che passare per
l'obrobrio di ODBC. Poi, che per ulteriore "comodita'"
l'interfaccia di VBMySQLDirect sia pressocche'
identica al modello ad oggetti di ADO e', appunto, solo
un'ulteriore comodita', che mi permette, volendo un
domani passare ad un altro DB di fare Trova-Sostituisci
"MYSQL_RS" con "ADODB.Recordset" e lasciare il resto
invariato.
Insomma, tanto di cappello a chi ha relizzato la DLL,
IMHO tuttaltro che una "tamarrata" =)
Just my 2 eurocent,
Lokar 

 ha scritto nel messaggio
news:dqik1n$9fi$1...@newsreader.mailgate.org...


 Come ho risolto ?? Ma semplice !!! Passando ad SQL Server... ;o)
Beh, se l'originale era in Access, probabilmente bastava anche un MSDE, 
che, al contrario di Sql-Server e MySql, è gratuito.


 MySQL.
Apri l'mdb con Access, file->carica_dati_esterni->collega_tabelle
Devi avere i driver MyODBC installati. Per questo wizard devi anche avere un
dsn che punti al db ed al server mysql.
Se tutto funge avrai ottenuto che access (e jet) faranno da ponte verso
mysql, attraverso odbc.
Ciao, Sandro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


Beh, sicuramente hai fatto un passo sensato. Peccato che, però, tu abbia
escluso a-priori mysql sulla base di una caratteristica non funzionante, a
fronte di tante altre che funzionano molto bene.


Se tutto funge avrai ottenuto che access (e jet) faranno da ponte verso
mysql, attraverso odbc.
  Il problema di questa soluzione e' che Tizio voleva riuscire ad avere
un sistema + stabile. Purtroppo questa soluzione, almeno per quella che
e' la mia esperienza, crea comunque grossi problemi di stabilita'
(anche se problemi di perdita di dati non dovrebbero esserci visto che
le tabelle stanno su MySQL). Inoltre, con questo sistema, molte query
che collegano piu' tabelle generano errori di vario tipo e vanno
riscritte (soprattutto le query di aggiornamento)

che ancora non supporta le Stored Procedures
Tizio chiedeva un sistema rapido x passare gradualmente da Access a
MySQL usando DAO senza dover riscrivere da subito tutto.
Il sistema che ho proposto e' quello che mi sembrava piu' percorribile.
Conosco VBMySQLDirect (anche se non l'ho mai usato) pero' per
integrarlo nel suo progetto deve x forza riscrivere tutto quanto direi.
Non ho mai provato perche' anche a me dava l'idea un po' di una
"tamarrata" e poi ho visto che era perennemente in versione Alpha e mi
dava l'idea di un progetto fermo. Qualcuno di voi lo hai mai usato?

 che ancora non supporta le Stored Procedures.
Anche questa soluzione non sarebbe niente male anche se mi costringerebbe a
molte modifiche. C'è un sito dove informarsi a fondo?
Grazie mille.
Ciao, Ciao.

 Come ho risolto ?? Ma semplice !!! Passando ad SQL Server... ;o)
Speriamo bene allora. Vedi è vero che faccio questo principalmente nel nome
della stabilità ma la ragione più importante è che sono troppo legato ad
Access per poter fare pratica a tempo perso su MySQL. Mentre invece io
vorrei in futuro lavorare esclusivamente con MySQL e PHP. Per questo che
questa cosa mi serve intanto per un primissimo approccio a MySQL, poi una
volta che lo uso in questo modo il passaggio successivo ed i primi
esperimenti con PHP verranno da soli, almeno spero. Che ci vuoi fare,
problemi dell'autodidatta.
Grazie mille comunque.
Ciao, Ciao.

 mysql, attraverso odbc.
Ti ringrazio molto, avevo letto in giro che si poteva fare infatti una cosa
del genere e sarà sicuramente il punto di partenza delle mie prove.
Ciao, Ciao.

 riscritte (soprattutto le query di aggiornamento)
Si in effetti mi serve più stabilità e non vorrei correre il rischio di
peggiorare i problemi invece di risolverli. Comunque una prova non mi
costerà nulla e spero di avere fortuna. Per quanto riguarda le query è vero
che ne definisco sempre una certa quantità nella sezione Query di Access, ma
il numero maggiore di interrogazioni al database le faccio da codice come
origine ai recordset. Praticamente ogni piccola operazione che una mia
maschera fa su di una tabella ricorre alla creazione di uno specifico
recordset che come origine ha la/le tabella/e destinatarie delle modifiche.
Ciao, Ciao.

 sono capitati sotto mano (MSDE, Sql Server, MySQL 4.1 e 5.0, ecc.)
Ciao, Grazie mille per le info. Cosa mi consiglieresti di fare quindi,
creare le tabelle in MySQL e poi allegare a queste quelle di Access passando
per i drivers ODBC? Ho letto in giro come realizzare questo collegamento,
spero di riuscirci al primo colpo, non ci ho mai provato. Infine per questo
tipo di struttura basta istallare MySQL oppure serve anche qualche
cos'altro?.
Grazie ancora.
Ciao, Ciao.

 cos'altro?.
Leggo che vuoi giungere a PHP+MySql.
Adesso però sei su VB+Access.
Devi valutare anche se nel periodo di transizione, ossia quando 
vorresti avere VB+MySql, il software resterà in tuo possesso, per 
sviluppo e test, o se andrà anche in produzione, cioè se verrà 
effettivamente usato operativamente.
In quest'ultimo caso, saresti obbligato a rendere disponibile tutto il 
sorgente, oppure a pagare la licenza di MySql (circa 
500Euri/anno/server).
Questo, solo per dire che io passerei a PHP+MySql direttamente, senza 
accrocchi intermedi.


 500Euri/anno/server).
Si in effetti a questo non avevo pensato proprio, dovrò tenerne conto. Ti
ringrazio per la delucidazione.
Ciao, Ciao.