MySQL: migrare dati da un DB ad un altro con adattamento

Dovendo realizzare una nuova versione di un importante sito di aste per beneficenza mi sono ritrovato a dover recuperare i dati degli utenti e delle associazioni ONLUS presenti nel database in uso reinserendoli nel database realizzato da me. Ovviamente, non si è trattato di copiare le vecchie tabelle nel nuovo database, sarebbe stato troppo semplice e questo articolo sarebbe stato pressoché inutile. Quello che invece ho dovuto realizzare sono stati una serie di script, in SQL e PHP, per recuperare questi dati. Un’occasione per rispolverare il mio SQL arrugginito.

Tabelle di partenza:

Partiamo dall’inizio. Il database di partenza, parliamo di MySQL, come detto, prevedeva una tabella principale contenente sia dati utenti sia associazioni e due tabelle secondarie con ulteriori dati sempre in comune discriminati dal numero ID di una delle due tabelle e da un numero di riferimento. In soldoni, spero di essere abbastanza chiaro, una delle due tabelle secondarie indicava il contenuto dei valori aggiuntivi nell’altra tabella secondaria. Sicuramente una soluzione ricavata dall’adattamento di un software ed un database non realizzato per questo scopo. Nella mia nuova versione volevo rendere la struttura del database un po’ più professionale e funzionale ma più semplice, con solo due diverse tabelle, una per gli utenti e una per le associazioni.

Tabelle di destinazione:

Ovviamente non posso pubblicare un dump per ovvi motivi di privacy.

Per complicare un po’ le cose, i campi da una tabella all’altra non sono ovviamente gli stessi, anzi, alcuni non servono più mentre ce ne sono dei nuovi. Inoltre le password erano codificate in Base64, una forma di codifica reversibile assolutamente non adatta a questo scopo. Insomma, vediamo cosa ho fatto…

Allora, per prima cosa recuperiamo i dati in comune prima per gli utenti e poi per le associazioni. Uno script SQL opportunamente modificato per le due situazioni, utenti e associazioni, permetterà di recuperare questi dati. Fortunatamente come discriminante tra i dati utenti e quelli delle associazioni vi è il campo della data di nascita, vuoto per associazioni e pieno per gli utenti:

Cambiando i nomi della tabella (nel codice vedete lo script per le “associazioni”) e dei campi si può usare lo stesso script  per travasare un ulteriore serie di dati in una seconda tabella, quella degli utenti. In questo modo abbiamo recuperato una serie di dati da una tabella del vecchio database a due tabelle del nuovo database.

Fin qui nessuna apparente difficoltà, adesso però dobbiamo recuperare le informazioni dalle due tabelle secondarie e qui la cosa si complica leggermente. Come dicevo, una tabella riporta una serie di valori di riferimento mentre nella seconda tabella secondaria vi sono questi valori, il tutto legato dagli ID.

Ecco quindi lo script che confronta il numero ID delle informazioni già recuperate con quello di una delle tabelle e recupera poi la relativa informazione:

Anche in questo caso, cambiando il nomi delle tabelle possiamo recuperare sia i dati utente che i dati associazioni.

A questo punto cambiamo le password da Base64 a MD5(salt+password), pertanto devo rimettere in chiaro le password e ricodificarle:

Ovviamente, per essere sicuro del risultato ho voluto fare qualche test prima ancora di utilizzare in modo definitivo i dati migrati. Ecco quindi un paio di script scritti apposta per la password.

Il primo script rimette la password originale:

Questo secondo script invece confronta una delle password con la nuova codifica per verificare se la conversione è riuscita:

Ecco quindi la cronaca di una giornata di lavoro passata solo a recuperare dati. Una libidine.

 

PDF Download    Invia l'articolo in formato PDF   

Non scegliete provider improvvisati!

Vi confesso che sono molto demoralizzato dalla mancanza di professionalità di alcuni provider o forse meglio dire dalla loro improvvisazione nel settore della fornitura di servizi e spazi web. Mi spiego riportando due esempi.

Qualche tempo fa, per un cliente, ho realizzato un ecommerce (tenete a mente il tipo di applicazione) su un provider toscano (ce ne sono tanti da quella regione quindi è inutile cercare di capire chi sia). Ci siamo accorti subito che non era possibile fare l’upload delle immagini poiché le cartelle del sito non avevano i permessi in scrittura, neanche i permessi privati.

Va bene, ho pensato ad una svista e infatti con una telefonata e alcuni email le cartelle necessarie sono state rese “scrivibili”. Non mi era mai capitato ma ci sta.

Qualche altra prova e vedo che ancora non è possibile fare upload di file usando il comando “move_upload_file()“. Fortunatamente nel mio ecommerce c’è un ben strutturato sistema di debug degli errori e noto l’impossibilità di scrivere nella cartella temporanea di PHP, quella indicata nella variabile “upload_tmp_dir” nel file “php.in“.

Lo faccio presente con un mail al reparto tecnico del provider e sapete cosa mi hanno risposto (faccio copia e incolla del mail):

Con la presente siamo a confermarLe l’avvenuta attivazione della cartella temporanea “upload_tmp_dir” necessaria per il corretto funzionamento del “file upload” tramite programmi php, con permessi di scrittura.

Avete letto bene, mi avevano creato una cartella “upload_tmp_dir” nella root! Devo ammettere che se non avessi dovuto consegnare a breve il lavoro mi sarei fatto anche una sana risata.

Nel frattempo avevano tolto tutti i permessi a tutte le cartelle riportando la situazione alla fase iniziale. Per farla breve, per poter risolvere la cosa, ho cancellato la mia cartella che richiedeva accessi in scrittura e ho rinominato la loro cartella “upload_tmp_dir” con il nome di quella che serviva a me acquisendo così i suoi permessi.

Ciliegina sulla torta? C’è c’è, vi ricordate che avevo scritto di prendere nota che il sito è un ecommerce? Bene, cosa fanno gli ecommerce quando si compra? Vi mandano un mail di conferma! Questo provider aveva pensato bene di disabilitare l’invio di posta dal server e, quando ha sbloccato la cosa dietro invio di mail, ha comunque impedito di inviare mail formattate HTML pertanto, le converme d’ordine, arrivano in HTML trasformato in testo. Un casino incomprensibile di caratteri.

Altro esempio. Un paio d’anni fa un altro cliente si serviva di un provider nella provincia di Terni rappresentato da un buffo omuncolo che si era improvvisato (e atteggiato) esperto in sicurezza. Talmente esperto che un giorno ho scoperto, per puro caso ( ;) ), che era possibile navigare liberamente dentro tutte le cartelle di tutti i domini all’interno del server. In pratica bastava usare le classiche istruzioni del PHP “dir”, “readdir” e “opendir” per navigare liberamente su tutto il server, cancellando, rinominando e volendo attuando la totale devastazione dei siti o ancora peggio l’inserimento di codice malevole.

In conclusione, quando scegliete un provider, cercate di controllarne prima le competenze chiedendo specifiche caratteristiche e permessi sul dominio che andate a registrare/realizzare. Fate girare diverso codice che impegni un po tutti gli aspetti e le attività che vi farete “girare” sopra. Cercate inltre di trovarne due o più di questi provider che soddisfino le vostre esigenze per avere una alternativa pronta e anche una differenza di prezzi da presentare ai vostri clienti.

Infine, quando il cliente vi dice “…ho già tutto io…” telefonate a casa che farete tardi!

PDF Creator    Invia l'articolo in formato PDF   

MySQL.Data in Visual C# 2005

Per quanti non comprendano perché non trovano MySQL.Data tra le referenze di Visual C# 2005 sotto Windows XP (cosa che invece avviene senza problemi in VB.NET 2005) fate così:

  • Installate il Connector da questo indirizzo: http://dev.mysql.com/downloads/connector/net/5.0.html
  • Aprite Riferimenti–>Aggiungi Riferimento e usate Sfoglia per cercare il file MySQL.Data.dll che si trova nella cartella C:\Programmi\MySQL\MySQL Connector Net 5.0.9\Binaries\.NET 2.0
  • Curiosamente, aprendo altri progetti, troverete MySQL.Data nella sezione NET, cosa che non avviene nel progetto nel quale mancava.

Inoltre per completezza d’informazione aggiungo un esempio di codice per la connessione:

PS: Auguri Nonna Elide.

PDF    Invia l'articolo in formato PDF   

MySQL E_FAIL e le date 0000-00-00

errore

Oggi sono diventato pazzo per un piccolo problemino legato alle date tra MySQL e i linguaggi di programmazione come VB6 e Delphi. Il problemino (adesso) è presto spiegato, se si legge un campo di un database MySQL, usando ODBC e ADO, che contiene date non reali si ottiene l’errore:

Data Provider or other service returned an E_FAIL

Non serve aggiornare MySQL all’ultima versione oppure gli ODBC o ancora cambiare versione di ADO, il problema è proprio nella lettura del campo MySQL. Certo che se la descrizione dell’errore fosse stata leggermente più intuitiva molti programmatori (soprattutto quello che scrive) avrebbero risparmiato un mucchio di tempo.

Per risolvere il problema è necessario mettere come data di default una data valida, anche scaduta, tipo 2000-01-01 e aggiungendo Not Null. In soldoni, il formato 0000-00-00 è l’equivalente del Null.

PDF Creator    Invia l'articolo in formato PDF