Stavo facendo un po' di esperimenti con MySql e Net 2.0 / VS2005 e ho scoperto che i problemi sono ancora tanti. Il Net Connector (MySql.Data.dll) è un buon prodotto se usato a basso livello ma ha ancora problemi se utilizzato con i vari wizard / utility di aiuto di visul studio. Andiamo con ordine.
La libreria funziona bene se si accetta di scrivere a mano il solito codice tedioso per l'accesso ai dati: creo una connessione, creo un command, gli imposto quello che serve, definisco e carico i parametri, apro la connessione, eseguo, leggo, ecc. ecc. ecc. Cose del tipo (esempio banale):
string dbConnString = Properties.Settings.Default.db1;
using (MySqlConnection dbConn = new MySqlConnection(dbConnString))
{
dbConn.Open();
using (MySqlCommand cmd = new MySqlCommand("select * from persone order by Cognome", dbConn))
{
MySqlDataReader reader = cmd.ExecuteReader();
while (reader.Read())
Console.WriteLine("> " + reader["IDpersona"] + "\t " + reader["Cognome"] );
reader.Close();
}
dbConn.Close();
}
Ma quando uno si rompe le scatole di scrivere queste cose, prova ad usare ad esempio i Typed DataSet. In passato
ne avevo già parlato: con sql 2005 funzionano bene anche se bisogna fare un po' di attenzione.
Oggi ho scoperto, con mio massimo dispiacere, che ci sono dei grossi problemi con MySql. Per ora la conclusione è: non funzionano! Troppi problemi e lacune. Provo a farne una lista:
- non ho trovato un modo per far aggiornare i dati di una datatable dopo l'insert. Caso tipico: un campo ID autoincremento. Dopo l'insert vorrei che l'ID riflettesse il valore assegnato dal motore di database. Con Sql funziona, con MySql no! Boh... spero di trovare una soluzione...
- le query autogenerate contengono sempre / spesso (?) il nome del database. Ad esempio invece di avere SELECT ID, Cognome, Nome FROM Persone c'è SELECT ID, Cognome, Nome FROM MyTestDB.Persone. Quel MyTestDB impedisce di "attaccare" un altro db con la stessa struttura ma nome diverso. Tipico: DBTest, DBProd, ecc. Bello vero? grrrr... Mi consola il fatto che sono bug noti (bug1) (bug2) . Speriamo...
- i campi autoincremento... non vengono riconosciuti come tali! Vengono visti come normali interi. Peggio di così.... Soluzione: impostarli a mano come autoincremento.
UPDATE 10/03/2009: per il problema dell'update dei campi AutoInc dopo l'inserimento bisogna intervenire a mano sul TableAdapter autocreato da VisualStudio. E' necessario inserire la query di select per l'aggiornamento dei dati. Esempio:
INSERT INTO persone (Cognome, Nome, Eta, IDCitta) VALUES (@Cognome, @Nome, @Eta, @IDCitta);
SELECT IDPersona,Cognome,Nome,Eta,IDCitta FROM persone WHERE (IDPersona = LAST_INSERT_ID());
Stesso discorso per il nome del database: bisogna toglierlo a mano.
Attenzione: non modificare il TableAdapter con il suo wizard (tasto destro "Configure..."). Le query di Insert, Update e Delete verrebbero rigenerate con la conseguente perdita di tutte le modifiche fatte a mano.
UPDATE 13/03/2009: soluzione al problema dei campi autoincremento non riconosciuti. Non è un problema del Net Connector ma di una caratteristica di documentata su
MSDN del metodo DataAdapter.FillSchema(). In pratica il campo per essere mappato correttamente come autoincremento deve essere di tipo Signed Int. Nei test che ho fatto io, il campo sul database MySql era INT UNSIGNED. In queste condizioni il designer di Visual Studio non era in grado di impostare in modo corretto la proprietà di autoincremento. E' bastato modificare il database mysql togliendo unsigned al campo.
.
