Showing posts with label asterisk. Show all posts
Showing posts with label asterisk. Show all posts

Tuesday, March 20, 2012

Asterisk in SQL

I'm trying to creat a search form and want to use the Like clause in my select statement so that a user can enter part of a word rather than the entire word. When I use this sql I get no results:

SELECT DISTINCT Keyword.CodeID FROM Keyword INNER JOIN Code ON Keyword.CodeID = Code.CodeID WHERE ((Keyword.Keyword)Like '*ARR*'AND (Code.ProgLang)='VB.NET') ORDER BY Keyword.CodeID

The problem is with the * . If I remove the * it works fine. If I use the code within Access rather than from my aspx code, it works fine. Is there a work around for this?

Hi,

% (percent) is the standard wildcard character. Access client does support *, but when you use it via OleDB (Jet provider) it also requires %.

Therefore put

SELECT DISTINCT Keyword.CodeID FROM Keyword INNER JOIN Code ON Keyword.CodeID = Code.CodeID WHERE ((Keyword.Keyword)Like '%ARR%'AND (Code.ProgLang)='VB.NET') ORDER BY Keyword.CodeID

|||That did it. Thanks!!!

asterisk in select_list in queries...

I have been using a subset of the SQL language for queries in FoxPro. I have
been advised against the use of the asterisk in the select_list portion of
queries based on slower performance due to no explicit column names to
instruct SQL Server which indices to utilize. Do you have a short
explanation on the validity of this advice? If so, and it is completely
valid, what are some shortcuts for writing queries where tables contain large
numbers of columns?
Best practice is to avoid using SELECT * in queries (except in an EXISTS
subquery or other subqueries that don't return data and aren't referenced by
an outer query).
Listing the column names makes sense in an N-Tier environment because you
want to make efficient use of network resources by returning to the client
only the data that is actually needed. This is an important difference from
a desktop, ISAM database like FoxPro where you have to retrieve a whole
record whether all the data is required or not.
Listing only the required columns also increases the opportunities for SQL
Server to optimize your query by making use of indexes.
Also, listing column names improves reliability and ease of maintenance. If
you later add another column you don't want to break existing code that
doesn't require that column. Use a column list and then just modify the code
that needs to reference the new column. If you use an asterisk in your
SELECT list then potentially more code could need modification and more code
would need to be unit-tested for each schema change.
Shortcuts? In Query Analyzer you can drag a list of column names from the
Object Browser into the query window. That can save you a lot of typing.
David Portas
SQL Server MVP

asterisk in select_list in queries...

I have been using a subset of the SQL language for queries in FoxPro. I have
been advised against the use of the asterisk in the select_list portion of
queries based on slower performance due to no explicit column names to
instruct SQL Server which indices to utilize. Do you have a short
explanation on the validity of this advice? If so, and it is completely
valid, what are some shortcuts for writing queries where tables contain large
numbers of columns?Best practice is to avoid using SELECT * in queries (except in an EXISTS
subquery or other subqueries that don't return data and aren't referenced by
an outer query).
Listing the column names makes sense in an N-Tier environment because you
want to make efficient use of network resources by returning to the client
only the data that is actually needed. This is an important difference from
a desktop, ISAM database like FoxPro where you have to retrieve a whole
record whether all the data is required or not.
Listing only the required columns also increases the opportunities for SQL
Server to optimize your query by making use of indexes.
Also, listing column names improves reliability and ease of maintenance. If
you later add another column you don't want to break existing code that
doesn't require that column. Use a column list and then just modify the code
that needs to reference the new column. If you use an asterisk in your
SELECT list then potentially more code could need modification and more code
would need to be unit-tested for each schema change.
Shortcuts? In Query Analyzer you can drag a list of column names from the
Object Browser into the query window. That can save you a lot of typing.
--
David Portas
SQL Server MVP
--