First off, change your style.
Stuff like this is hard to read:
SaveRecord(); Calculat(); SaveRecord1(); SaveRecord2(); LoanDetails();
reset(); tabControl1.SelectTab(tabPage1); txtCustomerName.Focus(); Autonumber1(); AutoDate1();
Separate each instruction on it's own line, and it becoems much more obvious:
SaveRecord();
Calculat();
SaveRecord1();
SaveRecord2();
LoanDetails();
reset();
tabControl1.SelectTab(tabPage1);
txtCustomerName.Focus();
Autonumber1();
AutoDate1();
And then change your method names to something more self documenting than "SaveRecord", "SaveRecord1", "SaveRecord2", and so on - it is far too easy to make mistakes when you just add a number on the end!
Then, the big one: 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. Always use Parameterized 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?
Now we start to get to the problem you have noticed - and we can't help. The code you show is doesn't even call the "Is Validated" method so that possibly a reason why your code fais with a duplicate key error - but we don't have any access to you data or user input so we can't tell wheat is going on at all.
So, it's 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. If you don't know how to use it then a quick Google for "Visual Studio 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. 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.
Sorry, but we can't do that for you - time for you to learn a new (and very, very useful) skill: debugging!