Without your actual database we can't be specific, but as Gerry says, "put the ID in the record". So add a "AuthorisedUser" column, and when you INSERT the row, set it to the ID of the user performing teh INSERT.
You can then add that to the WHERE clause when you do SELECT and UPDATE operations:
UPDATE ... WHERE AuthorisedUser = @UID AND RowID = ...
I suspect that is what your "insert_user" columns is there for, but we can;t realaly tell.
A couple of other things though:
1) Do yourself a favour, and stop using Visual Studio default names for everything - you may remember that "TextBox8" is the mobile number today, but when you have to modify it in three weeks time, will you then? Use descriptive names - "tbMobileNo" for example - and your code becomes easier to read, more self documenting, easier to maintain - and surprisingly quicker to code because Intellisense can get to to "tbMobile" in three keystrokes, where "TextBox8" takes thinking about and 8 keystrokes...
2) Check your columns types. You are passing text strings for every value there, and while that's probably right for Name, Surname, and so on, for "insert_user" it's probably very wrong, since that UserID is most likely a numeric IDENTITY field (or if it isn't it probably should be) - you shouldn't be storing a userID as a string more than once in the whole app!
Normally, you'd have two tables: one holding the user details: UserID, name, password... and a separate one that stores data. The use of a string here implies that you are using strings for everything, and that's a very poor idea which will give you problems later on. Always store values in the most appropriate type!
3) Always list your columns, never INSERT using default column order:
INSERT INTO MyTable ([Name], Surname, ...) VALUES (@NAME, @SURNAME, ...)
INSERT INTO MyTable VALUES (@NAME, @SURNAME, ...)
as that does two things: it makes your code more "future proof" - if the DB order gets changed your code doesn't fall over, or worse pout data in the wrong columns; and it means it still works when your row ID value (which if you don't have you damn well should) is an IDENTITY field. If you don't specify the columns, SQL will start from the "top most" column and assume the order, which is dangerous.
4) Rather than using
private void button1_Click(object sender, EventArgs e)
using (SqlConnection con = new SqlConnection(DALC.Getconnectionstring()))
using (SqlCommand cmd = new SqlCommand("...",con))
catch (SqlException ex)
That way, the DB objects will be closed and disposed automatically when they go out of scope.