Hello

I seem to have a problem with a UPDATE that just does not want to work. Im simpled it down to the most simple UPDATE possible and it simply does not want to work. Here is the simple version:

public static string CambiarDatosUsuarios(string usuario,string contr,string pregunta,string respuesta,string correo)
    {
        string res;
        try
        {
            comando = new MySqlCommand("UPDATE usuario SET pregunta=@preg,respuesta=@resp,email=@cor WHERE nombreu=@usud", conexion);
            comando.Parameters.Add("@usud", MySqlDbType.VarChar, 50).Value = usuario.ToUpper();
            comando.Parameters.Add("@preg", MySqlDbType.VarChar, 50).Value = pregunta;
            comando.Parameters.Add("@resp", MySqlDbType.VarChar, 50).Value = respuesta.ToUpper();
            comando.Parameters.Add("@cor", MySqlDbType.VarChar, 50).Value = correo;
            AbrirConexion();
            comando.ExecuteNonQuery();
            comando.Parameters.Clear();
            comando.Dispose();
            res = "Usuario actualizado con excito";
        }
        catch (Exception ex)
        {

            res = ex.Message;
        }
        finally
        {
            CerrarConexion();
        }
        return res;
    }

It gives NO errors but doesnt UPDATE any columns. I replaced it with a SELECT COUNT(*) and it works perfectly so I know I dont have column names or the table wrong.

If someone could help, thanks alot.

Dani AI

Generated

Quick, practical checklist for an UPDATE that runs without error but affects zero rows.

Capture the number of rows affected and dump the command + parameter values immediately after ExecuteNonQuery to see whether the WHERE actually matches any row:

int affected = comando.ExecuteNonQuery();
if (affected == 0)
{
    Console.WriteLine("No rows affected. SQL: " + comando.CommandText);
    foreach (MySqlParameter p in comando.Parameters)
        Console.WriteLine("{0} = '{1}'", p.ParameterName, p.Value ?? "NULL");
}

Common causes to verify (step-by-step):

  • Confirm the command's Connection object is the exact connection that was opened; different connection instances or a replaced connection can silently target the wrong session.
  • Verify the connection string/selected schema is the expected database (development vs production or another schema).
  • Check case-sensitivity/collation on the WHERE column. If the column is case-sensitive, either use a server-side function (UPPER(nombreu) = @usudUpper) or ensure the parameter matches the stored case.
  • Look for parameter truncation/type mismatches (too-small size, wrong DbType) that alter the comparison. Remove fixed small sizes while debugging.
  • Ensure there is no open transaction that wasn’t committed (or that autocommit was disabled). An uncommitted update will disappear when the session ends.
  • Confirm the DB user has UPDATE privileges for that table and that no trigger or ROLLBACK logic interferes.

Follow-up notes: raised disposing/parameter cleanup — move those actions into a finally block so resources are always released. ’s BLL idea can help design but won’t replace the above checks for this immediate symptom. Running the same UPDATE with literal values directly in a MySQL client is the fastest way to isolate app vs database behavior.

Recommended Answers

All 2 Replies

Member Avatar for Member #905211

What is the data type of the column nombreu and is it the tables primary key.

Also please try to start using stored procedures as they help prevent SQL injections and make it easier to modify your SQL and help with modularity.

Also do the clearing of parameters and disposing in the finally block, if there is an error the finally block will normally still be executed.

Hmm i think if you tried using a BUSINESS LOGIC LAYER to update the information it will work better for you.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.