We Keep Coding

Get line number of offending SQL from SqliteException

I am writing a simple SQL query tool using System.Data.SQLite. When the end user inputs SQL and executes it, I execute SQLiteCommand.ExecuteReader(). When that contains an error, a SQLiteException is thrown. I would like to help the user out by displaying the line number, within their SQL input, that has the error. Whereas .NET's System.Data.SqlClient.SqlException class has a collection of SqlError objects, each which contain a LineNumber property, I don't see anything like that in a SQLiteException. It has a Data property but that collection is empty when I inspect it.
I also checked the hierarchy of SQLiteException: it does not inherit from System.Data.SqlClient.SqlException.

This information is not provided by SQLite.

The variable name '#' has already been declared

Part of our solution is a page that displays company-specific information using an ASP Gridview. Our method of constructing the SQL that feeds the Gridview is by using C# to build a custom SELECT statement based on a series of user inputs.
Once the user applies their filters through a button click, C# loops through all of their selections (check boxes and text boxes) and then propagates those selections to a separate method which constructs a WHERE clause to append to a simple SELECT statement. We use a Table-Valued Function in the FROM statement, and the only input parameter is from the Querystring and this does not change throughout the process.
Once the query has been assembled using C#, we apply this query to the SqlDataSource as the Select Command. However, we have recently discovered a very bizarre SQL error that we haven’t seen before:
Errors :
"The variable name '#' has already been declared.
Variable names must be unique within a query batch or stored procedure."
We aren’t declaring any variables in our SQL. As stated above, the only input parameter comes from the Querystring, and we access this parameter using both QueryStringParameters in the ASP:SqlDataSource on the ASP side and “int.Parse(Request.QueryString["id"]).ToString()” on the C# side while constructing the SQL query.
After researching this error, I have yet to find an instance where the variable declaration is empty. Most people are getting errors similar to this when they have declared a variable such as '#email' or '#address' twice. We have no double declarations, and the fact that the variable in the error is not defined is causing a massive headache.
Has anyone seen anything like this before or have any suggestions on how to further debug?
I'll post some code if need be, but we are mostly interested to see if anyone has seen an error like this before.
Code:
string MainQueryStr = ResultsPages.SearchString(SearchVariables(), Request,
ProjectsSqlds, 0, "SELECT DISTINCT dbo.{0}.* FROM dbo.{0}(" + int.Parse(Request.QueryString["id"]).ToString() + ")",
"getXyzById", "AbcId");
StringBuilder SearchQueryStr = new StringBuilder();
SearchQueryStr.Append(MainQueryStr);
SearchQueryStr.Append(" ORDER BY AbcName");
ProjectsSqlds.SelectCommand = SearchQueryStr.ToString();
The search string function is a 500 line method that we can't post right now. It is used all over our solution and works as it should. It stitches together strings to create the query.
This is how the SearchString function appends the parameters:
l.Add(ResultsPages.NewSearchQueryString(ABCFiltersTxBx, SearchQueryStringVariableType.String,
"{1}.AbcID IN (" + ABCFiltersTxBx.Text + ")"));
Where the ABCFiltersTxBx is parsed into a comma separated string.

I should chime in as the supervisor in question here:
OK, so we figured out what was happening.
What we didn't realize was that the SQLDataSource was taking our appended WHERE clauses and using them as SelectParameters. Each parameter we wanted to add to the query that would ultimately feed the SQLDS was then being added as a SelectParameter without us realizing it, and because we hadn't made any explicit parameter declarations, the parameters were added with just "" as the name, leading to the error of "'#' has already been declared".
The most embarrassing part of this whole thing is that our API has already accounted for Parameter Names, but we had unwittingly excluded this part. Thank you all very much for reading and attempting to help. We thoroughly appreciate you taking your time to help us brainstorm our solution over here.
So I suppose the take-home of this whole error is in 2 parts:
Know your API. When you realize that you screwed it up on your own, graciously thank those that took the time to help you here on StackOverflow (or wherever you seek help), as their time is valuable as well.
"'#' is already declared" would indicate that you have parameters being declared without a name, so when debugging, look through the SQLDS you are using and find any parameters that haven't been explicitly named.
Again, thank you to all who read and offered to help. It's greatly appreciated.

c# System.Data.SQLite parameters error

I am using SQlite database on C# and have an error issue with parameters.
using System.Data.SQLite;
Here is a main code part:
this.dbUpdateCommand = new SQLiteCommand();
dbUpdateCommand.Parameters.AddWithValue("#paramNewValue", (string)this.valueNew);
dbUpdateCommand.Parameters.AddWithValue("#paramPredValue", (string)this.valuePred);
dbUpdateCommand.Parameters.AddWithValue("#paramTableName", (string) this.tableName);
dbUpdateCommand.Parameters.AddWithValue("#paramColumnName", (string)this.columnInDB);
dbUpdateCommand.Parameters.AddWithValue("#paramKeyField", (string)this.keyFieldInDB);
dbUpdateCommand.Parameters.AddWithValue("#paramKeyValue", (string)this.keyValueInDB);
dbUpdateCommand.CommandText = "UPDATE #paramTableName SET #paramColumnName=#paramNewValue WHERE #paramKeyField=#paramKeyValue;";
dbUpdateCommand.ExecuteNonQuery();
And it throws me exception "SQLite error near "#paramTableName": syntax error"
I tried to make pure SQL statement without params but with strings concatenation and it works with the same variables (this.tableName is valid db tablename)
So it seems something wrong with my parameters. Does anybody knows, what?

You can't use parameters to reference objects (tables & columns). You would need to drop the actual table and column names into your query. Be careful of SQL injection while doing so.

MySQL Adapter Fill Exception

I have a MySQL query I'm running from C#. I use the MySqlDataAdapter to fill a DataTable. However I am getting the following exception:
MySql.Data.Types.MySqlConversionException: Unable to convert MySQL date/time value to System.DateTime
I can't really modify the query (it's loaded from an external source). And I'm hoping I don't have to manually fill the data table. Anyone had this before?
I should also add I have tried adding allow zero datetime=no to the connection string with no success.

I think you made a mistake with your addition to the connection string! It should be:
Allow Zero Datetime = true

Execute query only if it is select statement. How?

string sqlQuery = "unknown";
I need to write a function which receives a sql query as parameter e.g. sqlQuery. I would like to execute it only if it is select statement and return data. In other case, if parameter sqlQuery contains delete, update or truncate, the function should return null.
I wonder if there is way to achieve this without parsing contents of parameter sqlQuery.
I would like to do this using c sharp for oracle queries.
Any tips. Thanks.
Update:
This should work for all kinds of users with all privileges.

Run the query in the context of a user who only has select privileges. Any other type of query will error out.

SET TRANSACTION READ ONLY, then execute the string. If it attempts to modify data, it will generate an ORA-01456 error. You can trap this and return whatever you want.

If you really have to work with a constructed string that will operate on the database, you should use the DBMS_ASSERT database package to make sure you have a pure query that's not subject to SQL injection. There's a nice paper on the Oracle site about that here.
The basics are:
only give the minimum privileges necessary, for example only giving the user "select" as described in an earlier reply. And then only on the minimum necessary set of tables. Views are really helpful here in limiting access.
Use bind variables where that's possible.
If you can't use bind variables then check the purity of your statement using DBMS_ASSERT

You can probably search the string for keywords like "update", "delete", "truncate" and all the other ways you can do ddl or dml on the table, but it is very error-prone. You have to eliminate strings in the query which might have these keywords and there are a lot of keywords that you have to take into account.
If your requirement is to return null, Why not give just the select privilege on the necessary objects and return null if you encounter the Insufficient Privileges error?
http://download.oracle.com/docs/cd/E11882_01/server.112/e17069/strms_trapply.htm#STRMS1065

I would not allow the client to specify a SQL select string. Too many possible attack vectors.
Have you considered using Linq? The caller could pass a Func<T, bool> that could be passed to a Where clause. Since Linq will generate the select statement for you, there's no possibility of a non-select statement occuring.

Bear in mind a SELECT column FROM table FOR UPDATE will still take an exclusive lock on every row on that table. And it only needs SELECT privileges (none of INSERT, UPDATE or DELETE are required).

You can use ADO.NET SqlCommand http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.aspx. It has methods ExecuteReader for a select type query and ExecuteNonQuery for other sql expression, you jest set the CommandText string attribute. If I'm right it throws exception if the query is not a select in ExecuteReader but you must check it.

string sqlQuery = "("+evil_sql+")";
Only a subquery can start with a parentheses. This will stop DML, DDL, and the FOR UPDATE issue that Gary mentioned. You still have to execute everything, just catch all the errors. I've done this on a public-facing website without any issues.
Even if your user is not directly granted anything you'll need to check for unnecessary PUBLIC grants. And of course keep your system patched. There have been exploits in functions that can be called in a SELECT.