If that doesn’t help, can you give us some idea of the values of variables as you run through debugging the PHP code.
Also these queries have a bit of “extra” that doesn’t seem needed, to me at least:
$sql2 = "UPDATE sattaNo SET id='2',FARIDABAD='$FARIDA' where id='2'";
$sql3 = "UPDATE sattaNo SET id='1',FARIDA='$FARIDA_1' where id='1'";
What’s the idea behind setting the id value when it already has that value? You only select rows where id=2 in the first one, so why set the value to 2 when it is already that? I should add I’m relatively new to SQL, so maybe there’s a reason for it, perhaps someone could clarify.
Once it’s working, as @SpacePhoenix said, you need to look at prepared statements to add security.
Well, upon making changes to the current snippet, you should already be making changes to the vulnerabilities. If you make the change to the SQL statement and it starts working, you’re doing double the work to make changes to the vulnerabilities.
I say you should be able to debug as you go, not debug when everything is finished. I think the problem also lies with the single quotes being wrapped around a variable in double quotes.
I don’t even use single quotes or anything like that since I use prepared statements in all my codes regardless if the WHERE clause is present or not. Makes it less difficult if I want to append a WHERE clause in the future.
The problem with OP’s snippet is that there are tons of legacy logic/ code in there. Only reason to use isset in $_POST is so that you can check whether that field has been tampered with via Inspect Element. Otherwise, supporting this logic only brings in horrible logic and design patterns. Hence why people are bashing about PHP so much.