How to correct 'error - input string not in correct format'

Can anyone help me correct this.

This line is giving an error

Code Snippet

dblAmount[2] = double .Parse (BD.dbCommands.ExecuteScalar("SELECT SUM([AR-PAYMENT AMOUNT]) " + strSql, BD.MyGlobal._ARConnection).ToString());

error = Input string not in correct format.

Code Snippet

public static object ExecuteScalar(string queryStr, OleDbConnection connStr)

{

if (connStr.State != ConnectionState.Open)

{

connStr.Open();

}

OleDbCommand comm = new OleDbCommand(queryStr, connStr);

object returnObject;

returnObject = comm.ExecuteScalar();

return returnObject;

}

You are attempting to convert the result of executing ExecuteScalar to a double. If the result is not in a format supported by double then you'll get an error. Try storing the results in a string first to verify the results are what you expected. If no resultset is returned then you'll get a null which will fail.

In general you should avoid combining so much code into one line. It doesn't help performance at all, makes debugging harder and is harder to read. Separate out function calls to make it easier for you.

Michael Taylor - 5/30/07

http://p3net.mvps.org

Thanks for the help - could you explain this further for me

"In general you should avoid combining so much code into one line. It doesn't help performance at all, makes debugging harder and is harder to read. Separate out function calls to make it easier for you."

There really isn't a lot to explain. Where does the problem lie in your code? You aren't sure because the following line is doing several different things.

Code Snippet

dblAmount[2] = double .Parse (BD.dbCommands.ExecuteScalar("SELECT SUM([AR-PAYMENT AMOUNT]) " + strSql, BD.MyGlobal._ARConnection).ToString());

It could lie in the call to Parse, ExecuteScalar, perhaps the strSql or _ARConnection variables or even the assignment to the array. Many different places where things can go wrong. Additionally a cursory glance makes it difficult to tell what exactly is being passed to Parse as a parameter. There are several sets of parenthesis.

You are having a hard time figuring out what is going wrong because this is one busy line. By breaking it up you can more easily figure out where the problem lies. Even better is the fact that you can single step through the debugger and confirm each line executes the way you want. By using the debugger you'll be able to quickly identify whether the result of ExecuteScalar is bad, the result from Parse is bad, whatever. Now imagine that you come back to this code 6 months later. Or worse yet someone else has to manage this code. It is a lot of extra work.

Many "old" C programmers would write code like this believing that the less source lines you have the smaller and faster the code would run. This simply is not true. The compiler will generate fast and optimal code whether you put code on one line or several lines. Therefore you should strive for readability of code over writing the smallest number of lines. There are places where it makes sense to consolidate lines but not here. Here is how I'd write the code if I were doing it:

Code Snippet

object result = BD.dbCommands.ExecuteScalar("SELECT SUM([AR-PAYMENT AMOUNT]) " + strSql, BD.MyGlobal._ARConnection);

string strResult = (result != null) ? result.ToString() : "0";

dblAmount[2] = double.Parse(strResult);

Now the above code is probably broken out more than I would normally do. I generally recommend that function calls reside on a line by themselves. Use variables to store the results. You can consolidate a method call to a variable (like .ToString()) in an assignment for simplicity. The important point is "where would I need to step through if something goes wrong". Functions are at the top of the list so break lines that way. Of course over time you'll find your own technique that works well for you but the above may help to get you started.

Michael Taylor - 5/30/07

http://p3net.mvps.org

Thanks very much for your advice, I am an 'old' VB programmer who is just getting into c# so everything helps.

I would also suggest preferring TryParse instead of Parse.