Non-clustered index on a field and a "%" sign

Folks,
I'm not sure, but if you have a non-clustered index on a field and
you have "%" character as the first character of the search parameter
does this bypass the index? In other words, do you need a certain
amount of characters before the % sign in SQL Server 2000?
Any comments/knowledge much appreciated,
Thanks,
Al.
Not necessarily. It does mean that a scan will be done, not a seek. Here's
a case where it will scan the NC index:
1) You have a NC index on ColA.
2) You run: SELECT ColA FROM MyTable WHERE ColA LIKE '%XYZ'
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
<almurph@.altavista.com> wrote in message
news:a8035a0d-7d2f-4ea4-9394-fc3b9b3c6247@.w34g2000hsg.googlegroups.com...
Folks,
I'm not sure, but if you have a non-clustered index on a field and
you have "%" character as the first character of the search parameter
does this bypass the index? In other words, do you need a certain
amount of characters before the % sign in SQL Server 2000?
Any comments/knowledge much appreciated,
Thanks,
Al.

Non-clustered index on a field and a "%" sign

Folks,
I'm not sure, but if you have a non-clustered index on a field and
you have "%" character as the first character of the search parameter
does this bypass the index? In other words, do you need a certain
amount of characters before the % sign in SQL Server 2000?
Any comments/knowledge much appreciated,
Thanks,
Al.Not necessarily. It does mean that a scan will be done, not a seek. Here's
a case where it will scan the NC index:
1) You have a NC index on ColA.
2) You run: SELECT ColA FROM MyTable WHERE ColA LIKE '%XYZ'
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
<almurph@.altavista.com> wrote in message
news:a8035a0d-7d2f-4ea4-9394-fc3b9b3c6247@.w34g2000hsg.googlegroups.com...
Folks,
I'm not sure, but if you have a non-clustered index on a field and
you have "%" character as the first character of the search parameter
does this bypass the index? In other words, do you need a certain
amount of characters before the % sign in SQL Server 2000?
Any comments/knowledge much appreciated,
Thanks,
Al.|||"almurph@.altavista.com" wrote:
> Folks,
> I'm not sure, but if you have a non-clustered index on a field and
> you have "%" character as the first character of the search parameter
> does this bypass the index? In other words, do you need a certain
> amount of characters before the % sign in SQL Server 2000?
> Any comments/knowledge much appreciated,
> Thanks,
> Al.
It disqualifies the seeking or partial scanning of the index. But as
mentioned by Tom, a full nonclustered index scan could still be used.
If you know that you will always have the % sign preceding the text, and
never after the text, then you could consider storing the data in
REVERSE order, or create a computed column on the REVERSE value, index
that, and use that column in your query.
For example: SELECT * FROM my_table WHERE reversed_domain LIKE
REVERSE('%.altavista.com')
Gert-Jan

Non-clustered index on a field and a "%" sign

Folks,
I'm not sure, but if you have a non-clustered index on a field and
you have "%" character as the first character of the search parameter
does this bypass the index? In other words, do you need a certain
amount of characters before the % sign in SQL Server 2000?
Any comments/knowledge much appreciated,
Thanks,
Al.Not necessarily. It does mean that a scan will be done, not a seek. Here's
a case where it will scan the NC index:
1) You have a NC index on ColA.
2) You run: SELECT ColA FROM MyTable WHERE ColA LIKE '%XYZ'
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
<almurph@.altavista.com> wrote in message
news:a8035a0d-7d2f-4ea4-9394-fc3b9b3c6247@.w34g2000hsg.googlegroups.com...
Folks,
I'm not sure, but if you have a non-clustered index on a field and
you have "%" character as the first character of the search parameter
does this bypass the index? In other words, do you need a certain
amount of characters before the % sign in SQL Server 2000?
Any comments/knowledge much appreciated,
Thanks,
Al.|||"almurph@.altavista.com" wrote:
> Folks,
> I'm not sure, but if you have a non-clustered index on a field and
> you have "%" character as the first character of the search parameter
> does this bypass the index? In other words, do you need a certain
> amount of characters before the % sign in SQL Server 2000?
> Any comments/knowledge much appreciated,
> Thanks,
> Al.
It disqualifies the seeking or partial scanning of the index. But as
mentioned by Tom, a full nonclustered index scan could still be used.
If you know that you will always have the % sign preceding the text, and
never after the text, then you could consider storing the data in
REVERSE order, or create a computed column on the REVERSE value, index
that, and use that column in your query.
For example: SELECT * FROM my_table WHERE reversed_domain LIKE
REVERSE('%.altavista.com')
--
Gert-Jan

nonclustered index fields

Hi folks,
I was wondering if it should be taken as a rule of thumb to allways avoid
the us of the fields that conform the primary key when we are designing any
nonclustered index, as in reality they allready have this key in "their
inside".
For example, say we have a pk composed of the fields: date, id
and then we create an index1 with fields : field1, date
and yet another index2 with just field: field1
Then, whenever I search in this simplistic example for field 1 between a
range of dates I allways get better performance with just the simple index.
The question is, will it happen allways or will it depend on the particular
queries and or situations?
Thanks in advance,
Tristan."Tristan" <Tristan@.discussions.microsoft.com> wrote in message
news:68D78CF8-E360-4365-9AE6-7CEA2D1C6C68@.microsoft.com...
> Hi folks,
> I was wondering if it should be taken as a rule of thumb to allways avoid
> the us of the fields that conform the primary key when we are designing
> any
> nonclustered index, as in reality they allready have this key in "their
> inside".
> For example, say we have a pk composed of the fields: date, id
> and then we create an index1 with fields : field1, date
> and yet another index2 with just field: field1
> Then, whenever I search in this simplistic example for field 1 between a
> range of dates I allways get better performance with just the simple
> index.
> The question is, will it happen allways or will it depend on the
> particular
> queries and or situations?
>
It depends. Often, for instance, you will have a non-clustered index on the
trailing column of a two-column clustered primary key. in your example a
non-clustered index on id would probably be appropriate to enable lookups by
ID. Even though the ID is replicated in the index leaf data, since it is
not the leading column in the clustered primary key, the clustered primary
key does not provide an efficient access path for lookups or sorting by ID.
David|||Tristan
You are confusing PK with clustered index. They are not the same thing.
Clustered index keys are contained in every NC index, but the clustered
index might not be on the primary key column(s).
However, if we assume you meant clustered index when you said pk, then you
answered your own questions. It completely depends on your queries and your
data distributions. A very general rule of thumb is that if you do a lot of
modifications, you want to keep your indexes to a minimum, so you wouldn't
have indexes with overlapping keys. But if you do mainly SELECTs, more
indexes can be useful, and having different leading columns can be a BIG
help. However, in your specific example, your index1 and index2 will be
identical in every way, so there is little reason to have both of them.
I wrote an article for SQL Server Magazine about a year ago on the reasons
why you might want to explicitly list one of your clustered index columns in
your nc index definitions.
http://www.sqlmag.com/Article/Artic...rver_44807.html
HTH
Kalen Delaney, SQL Server MVP
www.solidqualitylearning.com
"Tristan" <Tristan@.discussions.microsoft.com> wrote in message
news:68D78CF8-E360-4365-9AE6-7CEA2D1C6C68@.microsoft.com...
> Hi folks,
> I was wondering if it should be taken as a rule of thumb to allways avoid
> the us of the fields that conform the primary key when we are designing
> any
> nonclustered index, as in reality they allready have this key in "their
> inside".
> For example, say we have a pk composed of the fields: date, id
> and then we create an index1 with fields : field1, date
> and yet another index2 with just field: field1
> Then, whenever I search in this simplistic example for field 1 between a
> range of dates I allways get better performance with just the simple
> index.
> The question is, will it happen allways or will it depend on the
> particular
> queries and or situations?
> Thanks in advance,
> Tristan.|||Thanks lot Kalen & David for your replies. Indeed I pretendet to say
clustered when I used pk, thanks por pointing that out. Your answers have
being most clarifiying, thanks again,
Tristan.
"Kalen Delaney" wrote:

> Tristan
> You are confusing PK with clustered index. They are not the same thing.
> Clustered index keys are contained in every NC index, but the clustered
> index might not be on the primary key column(s).
> However, if we assume you meant clustered index when you said pk, then you
> answered your own questions. It completely depends on your queries and you
r
> data distributions. A very general rule of thumb is that if you do a lot o
f
> modifications, you want to keep your indexes to a minimum, so you wouldn't
> have indexes with overlapping keys. But if you do mainly SELECTs, more
> indexes can be useful, and having different leading columns can be a BIG
> help. However, in your specific example, your index1 and index2 will be
> identical in every way, so there is little reason to have both of them.
> I wrote an article for SQL Server Magazine about a year ago on the reasons
> why you might want to explicitly list one of your clustered index columns
in
> your nc index definitions.
> http://www.sqlmag.com/Article/Artic...rver_44807.html
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.solidqualitylearning.com
>
> "Tristan" <Tristan@.discussions.microsoft.com> wrote in message
> news:68D78CF8-E360-4365-9AE6-7CEA2D1C6C68@.microsoft.com...
>
>

Non blocking query on a table in SQL Server 2000

Hi Folks,
How can I invoke a non blocking ODBC query on a table in a SQL Server
database. Our current design requires the method invoking the query to
'return' immediately after invoking the query. The results of the query
should be put in a globally accessible location.
I think SQLFetch is a blocking call.
Thanks,
Vishal
*** Sent via Developersdex http://www.examnotes.net ***
Don't just participate in USENET...get rewarded for it!Vishal,
You have to use muliple threads. It is SQL Execute that usually takes
long time, not SQLFetch(). A call to single SQLFetch usually does not
take long unless you have some network connection problem.
Here is what you can do:
From your main application thread spawn a new one that does
SQLExecute(). The same spawned thread will call SQLFetch and put the
result in a shared buffer, possibly a global to you app. Then send a
Window message to you application notifying it that some data has be put
in the buffer. Read this data from your primary thread.
Regards,
Elvis
Dead not so long ago.
Vishal Prabhu wrote:

quote:

---

> Hi Folks,
> How can I invoke a non blocking ODBC query on a table in a SQL Server
> database. Our current design requires the method invoking the query to
> 'return' immediately after invoking the query. The results of the query
> should be put in a globally accessible location.
> I think SQLFetch is a blocking call.
> Thanks,
> Vishal
> *** Sent via Developersdex http://www.examnotes.net ***
> Don't just participate in USENET...get rewarded for it!

---

Non blocking query call

Hi Folks,
How can I invoke a non blocking ODBC query on a table in a SQL Server
database. Our current design requires the method invoking the query to
'return' immediately after invoking the query. The results of the
query should be put in a globally accessible location.
I think SQLFetch is a blocking call.
Thanks,
VishalWhat you are looking for is called Asynchronous Execution. You must enable
async using SQLSetConnectAttr() and SQL_ATTR_ASYNC_ENABLE.
ODBC APIs will return SQL_STILL_EXECUTING while the operation is still
pending. Once the operation completes, the API will return something other
than SQL_STILL_EXECUTING (SQL_SUCCESS if the operation succeeded, etc).
The async model exposed by ODBC is a Poll model, where you have to
periodically poll for completion (instead of a Notification model, where you
are notified that the operation completed).
Brannon Jones
Developer - MDAC
This posting is provided "as is" with no warranties and confers no rights.
"Vishal Prabhu" <vprabhu@.uci.edu> wrote in message
news:31cf0289.0312191118.4354c4fd@.posting.google.com...

quote:

---

> Hi Folks,
> How can I invoke a non blocking ODBC query on a table in a SQL Server
> database. Our current design requires the method invoking the query to
> 'return' immediately after invoking the query. The results of the
> query should be put in a globally accessible location.
> I think SQLFetch is a blocking call.
> Thanks,
> Vishal

---