The first problem is simple: 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?
The other is also simple: There is a path through that code where
income
is never assigned a value. If this test fails:
if (ds.Tables[0].Rows.Count > 0)
Then no value is assigned, and the subtraction can't take place. The same thing will occur with
withdrawal
later.
The system notices this and even if in the real world if could never occur it raises an error to let you know because it has no idea what your DB or session will contain at run time.
You
could fix this by assigning a default value, but a better solution is to handle the "no match" case yourself and exit the method while informing the user of the problem so he can let you know. Defaulting means you will potentially give the user the wrong information!
You should expect to get syntax errors every day, probably many times a day while you are coding - we all do regardless of how much experience we have! Sometimes, we misspell a variable, or a keyword; sometimes we forget to close a string or a code block. Sometimes the cat walks over your keyboard and types something really weird. Sometimes we just forget how many parameters a method call needs.
We all make mistakes.
And because we all do it, we all have to fix syntax errors - and it's a lot quicker to learn how and fix them yourself than to wait for someone else to fix them for you! So invest a little time in learning how to read error messages, and how to interpret your code as written in the light of what the compiler is telling you is wrong - it really is trying to be helpful!
So read this:
How to Write Code to Solve a Problem, A Beginner's Guide Part 2: Syntax Errors[
^] - it should help you next time you get a compilation error!
I'm not saying we don't want to help you fix them - sometimes I can't see my own errors because I read what I meant to write - but fixing syntax errors is part of the job, and if you can't do it for yourself people are going to look at you as a bit weird should you get a job in the industry!