Don't use method 2. Never use method 2. Never concatenate strings to build a SQL command. It leaves you wide open to accidental or deliberate SQL Injection attack which can destroy your entire database. Use Parametrized queries instead.
When you concatenate strings, you cause problems because SQL receives commands like:
SELECT * FROM MyTable WHERE StreetAddress = 'Baker's Wood'
The quote the user added terminates the string as far as SQL is concerned and you get problems. But it could be worse. If I come along and type this instead: "x';DROP TABLE MyTable;--" Then SQL receives a very different command:
SELECT * FROM MyTable WHERE StreetAddress = 'x';DROP TABLE MyTable;
Which SQL sees as three separate commands:
SELECT * FROM MyTable WHERE StreetAddress = 'x';
A perfectly valid SELECT
DROP TABLE MyTable;
A perfectly valid "delete the table" command
And everything else is a comment.
So it does: selects any matching rows, deletes the table from the DB, and ignores anything else.
So ALWAYS use parameterized queries! Or be prepared to restore your DB from backup frequently. You do take backups regularly, don't you?
If your code is not getting an error but the database is not getting updated, then that means the UPDATE WHERE clause matched no rows.
Why not? Well, that's the big question! It could be that the ID value you are passing is not what you thought, or you may be accessing the wrong DB, or the new values you are setting them to are the same as the old ones. We can't tell.
So, its going to be up to you.
Fortunately, you have a tool available to you which will help you find out what is going on: the debugger. How you use it depends on your compiler system, but a quick Google for the name of your IDE and "debugger" should give you the info you need.
Put a breakpoint on the first line in the function, and run your code through the debugger. Then look at your code, and at your data and work out what should happen manually. Look at your
id
variable and check exactly what it contains - is it the ID you expect? If it isn't, why not?
If it is, use SSMS to look at the DB content and examine that row. Does it exist? What are its current values? Are they different to the values you are passing?
Then single step each line checking that what you expected to happen is exactly what did. When it isn't, that's when you have a problem, and you can back-track (or run it again and look more closely) to find out why.
I'd also want to look at the return value from the SQL operation:
int rowsAffected = sql.ExecuteNonQuery();
Sorry, but we can't do that for you - time for you to learn a new (and very, very useful) skill: debugging!