Undefined function call lower()

Question

I am getting the following exception in my sqlite query:

The expression contains undefined function call lower()

I've got a very simple SQLite typed dataset in VS2012.

I'm parsing a large amount of data and want to check if a row already exists prior to adding a new row.

I'm using the .select() method to return an array of datarows. If the length of the array is zero I add a new new. Simple!

All has been working well, but I have added a check to prevent duplicate rows being added if the case is wrong. I am storing filenames.

The select statement is:

"lower(FileName) = '" + EscapeFileName(strFileName).ToLower() + "'"

However I get the above error on the lower(FileName). If I remove this is works fine, but obviously the check is not comparable.

The statement works as expected in SQLiteAdmin.

Answer 1

If I understand correctly, you have a .NET DataTable (the result of a query) and you are calling DataTable.Select(string) passing in a where clause.

This where clause is processed by .NET, not by SQLite (as pointed out by Tim). You cannot use SQLite (or any other DBMS) function in the Select function for the DataTable. You can use these functions:

• CONVERT – converts particular expression to a specified .NET Framework type
• LEN – gets the length of a string
• ISNULL – checks an expression and either returns the checked expression or a replacement value
• IIF – gets one of two values depending on the result of a logical expression
• TRIM – removes all leading and trailing blank characters like \r, \n, \t, ‚ ‘
• SUBSTRING – gets a sub-string of a specified length, starting at a specified point in the string

See DataView RowFilter Syntax [C#] for more information.

Answer 2

The statement works as expected in SQLiteAdmin.

The client-side data object does not invoke a server-side function but a client-side function.

EDIT: P.S. The DataTable has a CaseSensitive option which can be set to false.

P.P.S. Once you have the set of records in a .NET data object (i.e. your select has been executed and the row set has been retrieved) any further filtering of data by the data object's built-in methods (select, find, etc) are operating on the local, client-side disconnected data; a "conversation" with the database is not ongoing. These client-side methods are not "passing the instruction through" to the database. Read up on the Disconnected Recordset model.