Da Ms Access a MySql – 2

Nella prima parte abbiamo visto come usare il Migration Toolkit per convertire in un solo colpo un Db Access in uno MySql. Ora la domanda è: quanto è affidabile questa “traduzione” automatica ? Perchè è ovvio che non si tratta di prodotti identici, anzi, se vogliamo, sono assai diversi. Perciò è senz’altro opportuno approfondire l’argomento. Allora…

Migration Toolkit trasferisce solo la struttura delle Tabelle, gli Indici ed i Dati; quindi niente Relazioni (Chiavi Esterne ed Integrità Referenziale) e niente Query (la gestione di questo aspetto, nei due prodotti, è troppo diversa);

l’importazione avviene in un DataBase (chiamato Catalog o Schemata in MySql) che assume lo stesso nome del file .mdb d’origine; siccome in seguito non è propriamente semplice cambiare il nome del Db, è bene assegnare al file Access il nome che più vi garba prima del trasferimento;

i Valori Predefiniti dei Campi Numerici vengono impostati a null nella conversione: questo può essere un problema soprattutto per gli Indici ed i valori logici, quindi è necessario fare attenzione;

il tipo di campo Contatore di Access (spesso usato come Chiave primaria) viene correttamente convertito in un INT(10): però non viene assegnata la caratteristica di Auto Increment che quindi va aggiunta “a mano” nella Tabella di MySql;

la Chiave Primaria viene correttamente identificata ed assegnata, così come gli Indici;

un campo definito Intero in Access viene convertito in SMALLINT(5) in MySql, mentre Intero Lungo diventa INT(10): questo non comporta affatto una perdita di dati, sono solo modi diversi di indicare lo stesso intervallo di valori;

i Campi Access in Precisione Singola o Doppia diventano correttamente DOUBLE(), quindi tutti in Doppia Precisione con vari intervalli di valori ammessi;

nessun problema con i Campi Decimal quelli Data/Ora;

i Campi Valuta vengono correttamente convertiti in DECIMAL(19,4): se si desidera utilizzare solo due cifre decimali è necessario cambiare il formato;

il Campo Logico di Access diventa TINYINT(1); attenzione: il valore predefinito non viene impostato a zero (cioè Falso) e SOPRATTUTTO al valore Vero viene assegnato il numero “1″ e non “-1″ come in Access; qui è molto importante evitare errori: nel codice, per verificare un valore logico Vero usate sempre “.NOT. 0″ e non “=-1″;

il Campo Memo diventa senza difficoltà LONGTEXT;

Come abbiamo visto, i problemi sono davvero pochi: bisognerà comunque completare “a mano” una parte del lavoro, ma i tempi di migrazione sono accettabili. Resta da fare un’ultima cosa: se si desidera utilizzare il nuovo Db MySql con Access (collegando le Tabelle alla nostra applicazione) è opportuno controllare che per ogni Tabella esista una chiave primaria ed aggiungere ad ogni Tabella un Campo di tipo TIMESTAMP ad aggiornamento automatico. A questo proposito, tenete presente che:

quando si definisce un Campo TIMESTAMP MySql Administrator assegna un valore predefinito di zero; questo non è opportuno, perchè così il campo stesso non viene aggiornato alla modifica del Record ed Access ha difficoltà nel recuperare le informazioni; quindi in Administrator è necessario assegnare esplicitamente al TIMESTAMP il valore predefinito di null, ottenendo così correttamente CURRENT_TIMESTAMP;

Buon Lavoro