Question

I have a query like

SELECT *
FROM myTable
WHERE key LIKE 'XYZ'

The value 'XYZ' is entered by users (and may include % and _)

If I construct the query using string concatenation it runs in 10 seconds. But this is unsafe, and I should use a parameterised query.

So I'm constructing the query using the odbc command object and it's execute method, and passing a parameter.

SELECT *
FROM myTable
WHERE key LIKE ?

Unfortunately the parameterised SQL execute method takes a full minute.

This query is one of many that are part of a drill-down / investigation package, and I've had similar slow downs with all the parameterised queries (compared to string concatenation).

How do I find out where the time is going (and fix it) ?

Was it helpful?

Solution 2

Mitch had the right suggestion.

I had to change the connection string to use the OLEDB driver, then I could set the options:

  • Optimize Prepare=None
  • Select Method=Direct

OTHER TIPS

Here's my guess without further information.

I've had similar problems on SQL Server. In SQL Server when the column on your table is 'varchar' and the parameterised query parameter is 'nvarchar' (or vice versa), this causes SQL Server to ignore an available index because the parameter type doesn't match the index type, which in turn results in a table scan.

It's possible the same thing happens for Sybase. If you can see the generated query you can confirm if there's a type mismatch.

If this is the case, then two solutions would be

  • explicitly set the type of the parameter to match the column type
  • change the type of the column to match the parameter type being generated
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top