I have a query that should always be returning a single int. I have now logged it returning a string entirely unrelated to what it should be.
We\'ve been ge
I'm assuming that Settings.ConnString is read from Web.Config or the registry and is re-used other static routines. Could it be possible that there is a timing issue where a second method is executed prior to the call to cmd.ExecuteScalar() in your routine which modifies cmd.CommandText on the connection?
Hope this helps,
Bill
After a few months of ignoring this issue, it started to reach a critical mass as traffic gradually increased. We increased logging and found numerous definitive instances where, under heavy load, completely different result sets would get returned to unrelated queries.
We watched the queries in Profiler and were able to see that the bad results were always associated with the same spid, and that each bad result was always one query behind the actual sql statement being queried. It was like a result set got missed and whatever result set was next in the spid (from another connection in the same pool) was returned. Crazy.
Through trial and error, we eventually tracked down a handful of SqlCommand or LINQ queries whose SqlConnection wasn't closed immediately after use. Instead, through some sloppy programming originating from a misunderstanding of LINQ connections, the DataContext objects were disposed (and connections closed) only at the end of a request rather than immediately.
Once we refactored these methods to immediately close the connection with a C# "using" block (freeing up that pool for the next request), we received no more errors. While we still don't know the underlying reason that a connection pool would get so mixed up, we were able to cease all errors of this type. This problem was resolved in conjunction with another similar error I posted, found here: What Causes "Internal Connection Fatal Errors"?
I think neither your posted query nor LINQ are the problem.
Are you really sure you're looking at the right source? How is the method called? How is logging done?
Select isn't broken.
the Field "PkID" is a varchar/char in the "WebSite" Table.
If the "ISNULL" part of the query is true then it will return an integer (0), else it will return an string with the value of "PkID"
I think that you were thinking about sqlCommand.ExecuteNonQuery
that returns the number of rows affected within an int value...
This is the definition of the ExecuteScalar method:
public override object ExecuteScalar()
Member of System.Data.SqlClient.SqlCommand
Summary:
Executes the query, and returns the first column of the first row in the result set returned by the query. Additional columns or rows are ignored.
Returns:
The first column of the first row in the result set, or a null reference (Nothing in Visual Basic) if the result set is empty.
So, I think that the common way of returning that column is as a string representation of the column value.
I've recently seen a case where code was switching connection strings unexpectedly. For diagnostic purposes, please hard code the connection string and see if the problem goes away.
Also, for sanity's sake, please use nested using blocks like:
using(SqlConnection conn = new SqlConnection("hard-coded connection string"))
{
using (SqlCommand cmd = new SqlCommand(sql, conn))
{
// more init
object scalar = cmd.ExecuteScalar();
// process result
}
}
It wouldn't surprise me to find there are two database instances, and in one, PkID is an int, in another it's varchar.
Take a look with SQL Profiler to see if you can catch the return of "gladiator". In the other case I was working with, SQL Profiler showed nothing at all, indicating that the actual query was going to a different database.