Question when subtracting two queries

I want to return the difference number of records.

Here are the queries:

--subtracting columns with columns and descriptions (columns - columns and descriptions)
--difference of 30 records
--243
select
h.name as 'DataBase Name'
,t.name as 'Table Name'
,c.name as 'Column Name'
from sys.tables t
inner join sys.schemas h
on h.schema_id = t.schema_id
inner join sys.columns c
on t.object_id = c.object_id
and not exists
(
--213
select
h.name as 'DataBase Name'
,t.name as 'Table Name'
,c.name as 'Column Name'
from sys.extended_properties s
inner join sys.tables t
on s.major_id = t.object_id
inner join sys.schemas h
on h.schema_id = t.schema_id
inner join sys.columns c
on s.major_id = c.object_id
and s.minor_id = c.column_id
)

I'm not getting anything back. I should be getting back 30 records that have null descriptions.

Please help.Problem resolved. Thinking was off.

Quote:

Originally Posted by parkc

I want to return the difference number of records.

Here are the queries:

--subtracting columns with columns and descriptions (columns - columns and descriptions)
--difference of 30 records
--243
select
h.name as 'DataBase Name'
,t.name as 'Table Name'
,c.name as 'Column Name'
from sys.tables t
inner join sys.schemas h
on h.schema_id = t.schema_id
inner join sys.columns c
on t.object_id = c.object_id
and not exists
(
--213
select
h.name as 'DataBase Name'
,t.name as 'Table Name'
,c.name as 'Column Name'
from sys.extended_properties s
inner join sys.tables t
on s.major_id = t.object_id
inner join sys.schemas h
on h.schema_id = t.schema_id
inner join sys.columns c
on s.major_id = c.object_id
and s.minor_id = c.column_id
)

I'm not getting anything back. I should be getting back 30 records that have null descriptions.

Please help.

|||

Quote:

Originally Posted by parkc

I want to return the difference number of records.

Here are the queries:

--subtracting columns with columns and descriptions (columns - columns and descriptions)
--difference of 30 records
--243
select
h.name as 'DataBase Name'
,t.name as 'Table Name'
,c.name as 'Column Name'
from sys.tables t
inner join sys.schemas h
on h.schema_id = t.schema_id
inner join sys.columns c
on t.object_id = c.object_id
and not exists
(
--213
select
h.name as 'DataBase Name'
,t.name as 'Table Name'
,c.name as 'Column Name'
from sys.extended_properties s
inner join sys.tables t
on s.major_id = t.object_id
inner join sys.schemas h
on h.schema_id = t.schema_id
inner join sys.columns c
on s.major_id = c.object_id
and s.minor_id = c.column_id
)

I'm not getting anything back. I should be getting back 30 records that have null descriptions.

Please help.

TRY below query and check if that works...

select * from
(
select h.name as 'DataBase Name',t.name as 'Table Name',c.name as 'Column Name'
from sys.tables t
inner join sys.schemas h on h.schema_id = t.schema_id
inner join sys.columns c on t.object_id = c.object_id
) x
left outer join
(
--213
select h.name as 'DataBase Name',t.name as 'Table Name',c.name as 'Column Name'
from sys.extended_properties s
inner join sys.tables t on s.major_id = t.object_id
inner join sys.schemas h on h.schema_id = t.schema_id
inner join sys.columns c
on s.major_id = c.object_id
and s.minor_id = c.column_id
) y on x.[DataBase Name] = y.[DataBase Name]
where y.[DataBase Name] is null

Question on SQL Profiler

I am running a trace on a set of queries. What I am noticing is that the
duration for all the individual SQL statment within the batch is minimal but
yet the total duration for the same batch completed is a lot more than if I
added the duration for individul SQL statements. So my question is where is
the remaining time coming from? How do I speed that up if I do not know what
is causing the batch to take longer time?
Thanks
Try checking out how the sql queries are being executed on the client side if possible. Usually, there are other things involved like recompilations and/or sql prepare operations and/or cursor fetch(es). ODBC calls usually do this and run sp_cursoropen, s
p_prepare, sp_cursorfetch, ..., etc... Try looking at RPC's and SQL's on the profiler... =)

question on SELECT 1 and Profiler

I am testing sql 2005 queries using the sql server 2005 jdbc 1.1 driver
and I see a lot of SELECT 1 statements that are running longer in sql
2005 than in sql 2000. what are these select 1 statements?
"Derek" <gepetto_2000@.yahoo.com> wrote in message
news:1164034938.054630.206620@.k70g2000cwa.googlegr oups.com...
> I am testing sql 2005 queries using the sql server 2005 jdbc 1.1 driver
> and I see a lot of SELECT 1 statements that are running longer in sql
> 2005 than in sql 2000. what are these select 1 statements?
>
SELECT 1
Is a query that returns a single row and a single column containing the
value 1. It's extremely cheap, and probably being used as kind of "ping"
from some application. It's such a cheap query that its cost is probably
just background noise.
David
|||How much longer? 1,000 times longer? SQL Server 2005's profiler can
track time in Miliseconds or Microseconds. I believe the default is
microseconds. If something took 1 ms (would not have shown that level
of detail, but just for an example.. In 2000 I believe the lowest level
of detail visible was about 10 or 12 ms, one of the reasons the
microseconds are used, to provide much more detail over the life of a
query and it's trending time) in 2005 profiler under microseconds it
would be 1,000 (still 1 milisecond, however).
David Browne wrote:
> "Derek" <gepetto_2000@.yahoo.com> wrote in message
> news:1164034938.054630.206620@.k70g2000cwa.googlegr oups.com...
> SELECT 1
> Is a query that returns a single row and a single column containing the
> value 1. It's extremely cheap, and probably being used as kind of "ping"
> from some application. It's such a cheap query that its cost is probably
> just background noise.
> David
|||First of all, the SELECT 1 query is used by Connection Pools to maintain
those connections as "live" so the pool manager does not close them. Only
the base connections should be executing them; otherwise, the pool would
never shrink.
Next, when you say 1,000 times longer, I'm not sure what you mean. On a
SS2K instance, run a script of a loop of SELECT 1 for 5,000 times. Now,
execute the same script on SS2K5. What are the average per execution
duration and the overall duration for each of these installations?
Now, there can be environmental factors that you should be careful about,
and I would prefer to run these against each instance, but on the same
hardware, but they should still be roughly the same. There's just not a
whole lot of improvements a system could make on such a simple query.
Sincerely,
Anthony Thomas

"MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
news:1164074119.932839.211510@.j44g2000cwa.googlegr oups.com...[vbcol=seagreen]
> How much longer? 1,000 times longer? SQL Server 2005's profiler can
> track time in Miliseconds or Microseconds. I believe the default is
> microseconds. If something took 1 ms (would not have shown that level
> of detail, but just for an example.. In 2000 I believe the lowest level
> of detail visible was about 10 or 12 ms, one of the reasons the
> microseconds are used, to provide much more detail over the life of a
> query and it's trending time) in 2005 profiler under microseconds it
> would be 1,000 (still 1 milisecond, however).
>
> David Browne wrote:
driver[vbcol=seagreen]
"ping"[vbcol=seagreen]
probably
>
|||Anthony,
I am not the OP. I did not discuss what the SELECT 1 was. The original
poster indicated that when using profiler, a SELECT 1 query is taking a
lot (never indicated by what factor) longer to run. (Presumably when
looking at Duration in Profiler)
My reply indicated that in SQL Server 2005 you can view your Duration
event in Micro or Miliseconds. In SQL Server 2000 the duration shows
only in miliseconds. I was suggesting that the default behavior (which,
I believe is to view duration in MICROseconds) is probably what is
making the OP's SELECT 1 query appear to run a lot longer in SQL Server
2005. A microsecond is 1,000 times longer than a milisecond.
Sorry that wasn't clear.
Anthony Thomas wrote:[vbcol=seagreen]
> First of all, the SELECT 1 query is used by Connection Pools to maintain
> those connections as "live" so the pool manager does not close them. Only
> the base connections should be executing them; otherwise, the pool would
> never shrink.
> Next, when you say 1,000 times longer, I'm not sure what you mean. On a
> SS2K instance, run a script of a loop of SELECT 1 for 5,000 times. Now,
> execute the same script on SS2K5. What are the average per execution
> duration and the overall duration for each of these installations?
> Now, there can be environmental factors that you should be careful about,
> and I would prefer to run these against each instance, but on the same
> hardware, but they should still be roughly the same. There's just not a
> whole lot of improvements a system could make on such a simple query.
> Sincerely,
>
> Anthony Thomas
>
> --
> "MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
> news:1164074119.932839.211510@.j44g2000cwa.googlegr oups.com...
> driver
> "ping"
> probably
|||Yes, I think your analysis is correct. But, when in doubt, test it out. If
anything, just out of curiosity.
Anthony Thomas

"MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
news:1164129078.760070.81590@.j44g2000cwa.googlegro ups.com...[vbcol=seagreen]
> Anthony,
> I am not the OP. I did not discuss what the SELECT 1 was. The original
> poster indicated that when using profiler, a SELECT 1 query is taking a
> lot (never indicated by what factor) longer to run. (Presumably when
> looking at Duration in Profiler)
> My reply indicated that in SQL Server 2005 you can view your Duration
> event in Micro or Miliseconds. In SQL Server 2000 the duration shows
> only in miliseconds. I was suggesting that the default behavior (which,
> I believe is to view duration in MICROseconds) is probably what is
> making the OP's SELECT 1 query appear to run a lot longer in SQL Server
> 2005. A microsecond is 1,000 times longer than a milisecond.
> Sorry that wasn't clear.
>
> Anthony Thomas wrote:
Only[vbcol=seagreen]
about,[vbcol=seagreen]
level[vbcol=seagreen]
sql[vbcol=seagreen]
the
>

question on SELECT 1 and Profiler

I am testing sql 2005 queries using the sql server 2005 jdbc 1.1 driver
and I see a lot of SELECT 1 statements that are running longer in sql
2005 than in sql 2000. what are these select 1 statements?"Derek" <gepetto_2000@.yahoo.com> wrote in message
news:1164034938.054630.206620@.k70g2000cwa.googlegroups.com...
> I am testing sql 2005 queries using the sql server 2005 jdbc 1.1 driver
> and I see a lot of SELECT 1 statements that are running longer in sql
> 2005 than in sql 2000. what are these select 1 statements?
>
SELECT 1
Is a query that returns a single row and a single column containing the
value 1. It's extremely cheap, and probably being used as kind of "ping"
from some application. It's such a cheap query that its cost is probably
just background noise.
David|||How much longer? 1,000 times longer? SQL Server 2005's profiler can
track time in Miliseconds or Microseconds. I believe the default is
microseconds. If something took 1 ms (would not have shown that level
of detail, but just for an example.. In 2000 I believe the lowest level
of detail visible was about 10 or 12 ms, one of the reasons the
microseconds are used, to provide much more detail over the life of a
query and it's trending time) in 2005 profiler under microseconds it
would be 1,000 (still 1 milisecond, however).
David Browne wrote:
> "Derek" <gepetto_2000@.yahoo.com> wrote in message
> news:1164034938.054630.206620@.k70g2000cwa.googlegroups.com...
> SELECT 1
> Is a query that returns a single row and a single column containing the
> value 1. It's extremely cheap, and probably being used as kind of "ping"
> from some application. It's such a cheap query that its cost is probably
> just background noise.
> David|||First of all, the SELECT 1 query is used by Connection Pools to maintain
those connections as "live" so the pool manager does not close them. Only
the base connections should be executing them; otherwise, the pool would
never shrink.
Next, when you say 1,000 times longer, I'm not sure what you mean. On a
SS2K instance, run a script of a loop of SELECT 1 for 5,000 times. Now,
execute the same script on SS2K5. What are the average per execution
duration and the overall duration for each of these installations?
Now, there can be environmental factors that you should be careful about,
and I would prefer to run these against each instance, but on the same
hardware, but they should still be roughly the same. There's just not a
whole lot of improvements a system could make on such a simple query.
Sincerely,
Anthony Thomas
"MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
news:1164074119.932839.211510@.j44g2000cwa.googlegroups.com...
> How much longer? 1,000 times longer? SQL Server 2005's profiler can
> track time in Miliseconds or Microseconds. I believe the default is
> microseconds. If something took 1 ms (would not have shown that level
> of detail, but just for an example.. In 2000 I believe the lowest level
> of detail visible was about 10 or 12 ms, one of the reasons the
> microseconds are used, to provide much more detail over the life of a
> query and it's trending time) in 2005 profiler under microseconds it
> would be 1,000 (still 1 milisecond, however).
>
> David Browne wrote:
driver[vbcol=seagreen]
"ping"[vbcol=seagreen]
probably[vbcol=seagreen]
>|||Anthony,
I am not the OP. I did not discuss what the SELECT 1 was. The original
poster indicated that when using profiler, a SELECT 1 query is taking a
lot (never indicated by what factor) longer to run. (Presumably when
looking at Duration in Profiler)
My reply indicated that in SQL Server 2005 you can view your Duration
event in Micro or Miliseconds. In SQL Server 2000 the duration shows
only in miliseconds. I was suggesting that the default behavior (which,
I believe is to view duration in MICROseconds) is probably what is
making the OP's SELECT 1 query appear to run a lot longer in SQL Server
2005. A microsecond is 1,000 times longer than a milisecond.
Sorry that wasn't clear.
Anthony Thomas wrote:[vbcol=seagreen]
> First of all, the SELECT 1 query is used by Connection Pools to maintain
> those connections as "live" so the pool manager does not close them. Only
> the base connections should be executing them; otherwise, the pool would
> never shrink.
> Next, when you say 1,000 times longer, I'm not sure what you mean. On a
> SS2K instance, run a script of a loop of SELECT 1 for 5,000 times. Now,
> execute the same script on SS2K5. What are the average per execution
> duration and the overall duration for each of these installations?
> Now, there can be environmental factors that you should be careful about,
> and I would prefer to run these against each instance, but on the same
> hardware, but they should still be roughly the same. There's just not a
> whole lot of improvements a system could make on such a simple query.
> Sincerely,
>
> Anthony Thomas
>
> --
> "MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
> news:1164074119.932839.211510@.j44g2000cwa.googlegroups.com...
> driver
> "ping"
> probably|||Yes, I think your analysis is correct. But, when in doubt, test it out. If
anything, just out of curiosity.
Anthony Thomas
"MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
news:1164129078.760070.81590@.j44g2000cwa.googlegroups.com...
> Anthony,
> I am not the OP. I did not discuss what the SELECT 1 was. The original
> poster indicated that when using profiler, a SELECT 1 query is taking a
> lot (never indicated by what factor) longer to run. (Presumably when
> looking at Duration in Profiler)
> My reply indicated that in SQL Server 2005 you can view your Duration
> event in Micro or Miliseconds. In SQL Server 2000 the duration shows
> only in miliseconds. I was suggesting that the default behavior (which,
> I believe is to view duration in MICROseconds) is probably what is
> making the OP's SELECT 1 query appear to run a lot longer in SQL Server
> 2005. A microsecond is 1,000 times longer than a milisecond.
> Sorry that wasn't clear.
>
> Anthony Thomas wrote:
Only[vbcol=seagreen]
about,[vbcol=seagreen]
level[vbcol=seagreen]
sql[vbcol=seagreen]
the[vbcol=seagreen]
>

question on SELECT 1 and Profiler

I am testing sql 2005 queries using the sql server 2005 jdbc 1.1 driver
and I see a lot of SELECT 1 statements that are running longer in sql
2005 than in sql 2000. what are these select 1 statements?"Derek" <gepetto_2000@.yahoo.com> wrote in message
news:1164034938.054630.206620@.k70g2000cwa.googlegroups.com...
> I am testing sql 2005 queries using the sql server 2005 jdbc 1.1 driver
> and I see a lot of SELECT 1 statements that are running longer in sql
> 2005 than in sql 2000. what are these select 1 statements?
>
SELECT 1
Is a query that returns a single row and a single column containing the
value 1. It's extremely cheap, and probably being used as kind of "ping"
from some application. It's such a cheap query that its cost is probably
just background noise.
David|||How much longer? 1,000 times longer? SQL Server 2005's profiler can
track time in Miliseconds or Microseconds. I believe the default is
microseconds. If something took 1 ms (would not have shown that level
of detail, but just for an example.. In 2000 I believe the lowest level
of detail visible was about 10 or 12 ms, one of the reasons the
microseconds are used, to provide much more detail over the life of a
query and it's trending time) in 2005 profiler under microseconds it
would be 1,000 (still 1 milisecond, however).
David Browne wrote:
> "Derek" <gepetto_2000@.yahoo.com> wrote in message
> news:1164034938.054630.206620@.k70g2000cwa.googlegroups.com...
> >
> > I am testing sql 2005 queries using the sql server 2005 jdbc 1.1 driver
> > and I see a lot of SELECT 1 statements that are running longer in sql
> > 2005 than in sql 2000. what are these select 1 statements?
> >
> SELECT 1
> Is a query that returns a single row and a single column containing the
> value 1. It's extremely cheap, and probably being used as kind of "ping"
> from some application. It's such a cheap query that its cost is probably
> just background noise.
> David|||First of all, the SELECT 1 query is used by Connection Pools to maintain
those connections as "live" so the pool manager does not close them. Only
the base connections should be executing them; otherwise, the pool would
never shrink.
Next, when you say 1,000 times longer, I'm not sure what you mean. On a
SS2K instance, run a script of a loop of SELECT 1 for 5,000 times. Now,
execute the same script on SS2K5. What are the average per execution
duration and the overall duration for each of these installations?
Now, there can be environmental factors that you should be careful about,
and I would prefer to run these against each instance, but on the same
hardware, but they should still be roughly the same. There's just not a
whole lot of improvements a system could make on such a simple query.
Sincerely,
Anthony Thomas
"MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
news:1164074119.932839.211510@.j44g2000cwa.googlegroups.com...
> How much longer? 1,000 times longer? SQL Server 2005's profiler can
> track time in Miliseconds or Microseconds. I believe the default is
> microseconds. If something took 1 ms (would not have shown that level
> of detail, but just for an example.. In 2000 I believe the lowest level
> of detail visible was about 10 or 12 ms, one of the reasons the
> microseconds are used, to provide much more detail over the life of a
> query and it's trending time) in 2005 profiler under microseconds it
> would be 1,000 (still 1 milisecond, however).
>
> David Browne wrote:
> > "Derek" <gepetto_2000@.yahoo.com> wrote in message
> > news:1164034938.054630.206620@.k70g2000cwa.googlegroups.com...
> > >
> > > I am testing sql 2005 queries using the sql server 2005 jdbc 1.1
driver
> > > and I see a lot of SELECT 1 statements that are running longer in sql
> > > 2005 than in sql 2000. what are these select 1 statements?
> > >
> >
> > SELECT 1
> >
> > Is a query that returns a single row and a single column containing the
> > value 1. It's extremely cheap, and probably being used as kind of
"ping"
> > from some application. It's such a cheap query that its cost is
probably
> > just background noise.
> >
> > David
>|||Anthony,
I am not the OP. I did not discuss what the SELECT 1 was. The original
poster indicated that when using profiler, a SELECT 1 query is taking a
lot (never indicated by what factor) longer to run. (Presumably when
looking at Duration in Profiler)
My reply indicated that in SQL Server 2005 you can view your Duration
event in Micro or Miliseconds. In SQL Server 2000 the duration shows
only in miliseconds. I was suggesting that the default behavior (which,
I believe is to view duration in MICROseconds) is probably what is
making the OP's SELECT 1 query appear to run a lot longer in SQL Server
2005. A microsecond is 1,000 times longer than a milisecond.
Sorry that wasn't clear.
Anthony Thomas wrote:
> First of all, the SELECT 1 query is used by Connection Pools to maintain
> those connections as "live" so the pool manager does not close them. Only
> the base connections should be executing them; otherwise, the pool would
> never shrink.
> Next, when you say 1,000 times longer, I'm not sure what you mean. On a
> SS2K instance, run a script of a loop of SELECT 1 for 5,000 times. Now,
> execute the same script on SS2K5. What are the average per execution
> duration and the overall duration for each of these installations?
> Now, there can be environmental factors that you should be careful about,
> and I would prefer to run these against each instance, but on the same
> hardware, but they should still be roughly the same. There's just not a
> whole lot of improvements a system could make on such a simple query.
> Sincerely,
>
> Anthony Thomas
>
> --
> "MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
> news:1164074119.932839.211510@.j44g2000cwa.googlegroups.com...
> > How much longer? 1,000 times longer? SQL Server 2005's profiler can
> > track time in Miliseconds or Microseconds. I believe the default is
> > microseconds. If something took 1 ms (would not have shown that level
> > of detail, but just for an example.. In 2000 I believe the lowest level
> > of detail visible was about 10 or 12 ms, one of the reasons the
> > microseconds are used, to provide much more detail over the life of a
> > query and it's trending time) in 2005 profiler under microseconds it
> > would be 1,000 (still 1 milisecond, however).
> >
> >
> > David Browne wrote:
> > > "Derek" <gepetto_2000@.yahoo.com> wrote in message
> > > news:1164034938.054630.206620@.k70g2000cwa.googlegroups.com...
> > > >
> > > > I am testing sql 2005 queries using the sql server 2005 jdbc 1.1
> driver
> > > > and I see a lot of SELECT 1 statements that are running longer in sql
> > > > 2005 than in sql 2000. what are these select 1 statements?
> > > >
> > >
> > > SELECT 1
> > >
> > > Is a query that returns a single row and a single column containing the
> > > value 1. It's extremely cheap, and probably being used as kind of
> "ping"
> > > from some application. It's such a cheap query that its cost is
> probably
> > > just background noise.
> > >
> > > David
> >|||Yes, I think your analysis is correct. But, when in doubt, test it out. If
anything, just out of curiosity.
Anthony Thomas
"MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
news:1164129078.760070.81590@.j44g2000cwa.googlegroups.com...
> Anthony,
> I am not the OP. I did not discuss what the SELECT 1 was. The original
> poster indicated that when using profiler, a SELECT 1 query is taking a
> lot (never indicated by what factor) longer to run. (Presumably when
> looking at Duration in Profiler)
> My reply indicated that in SQL Server 2005 you can view your Duration
> event in Micro or Miliseconds. In SQL Server 2000 the duration shows
> only in miliseconds. I was suggesting that the default behavior (which,
> I believe is to view duration in MICROseconds) is probably what is
> making the OP's SELECT 1 query appear to run a lot longer in SQL Server
> 2005. A microsecond is 1,000 times longer than a milisecond.
> Sorry that wasn't clear.
>
> Anthony Thomas wrote:
> > First of all, the SELECT 1 query is used by Connection Pools to maintain
> > those connections as "live" so the pool manager does not close them.
Only
> > the base connections should be executing them; otherwise, the pool would
> > never shrink.
> >
> > Next, when you say 1,000 times longer, I'm not sure what you mean. On a
> > SS2K instance, run a script of a loop of SELECT 1 for 5,000 times. Now,
> > execute the same script on SS2K5. What are the average per execution
> > duration and the overall duration for each of these installations?
> >
> > Now, there can be environmental factors that you should be careful
about,
> > and I would prefer to run these against each instance, but on the same
> > hardware, but they should still be roughly the same. There's just not a
> > whole lot of improvements a system could make on such a simple query.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> >
> > --
> >
> > "MikeWalsh" <mwalsh9815@.gmail.com> wrote in message
> > news:1164074119.932839.211510@.j44g2000cwa.googlegroups.com...
> > > How much longer? 1,000 times longer? SQL Server 2005's profiler can
> > > track time in Miliseconds or Microseconds. I believe the default is
> > > microseconds. If something took 1 ms (would not have shown that level
> > > of detail, but just for an example.. In 2000 I believe the lowest
level
> > > of detail visible was about 10 or 12 ms, one of the reasons the
> > > microseconds are used, to provide much more detail over the life of a
> > > query and it's trending time) in 2005 profiler under microseconds it
> > > would be 1,000 (still 1 milisecond, however).
> > >
> > >
> > > David Browne wrote:
> > > > "Derek" <gepetto_2000@.yahoo.com> wrote in message
> > > > news:1164034938.054630.206620@.k70g2000cwa.googlegroups.com...
> > > > >
> > > > > I am testing sql 2005 queries using the sql server 2005 jdbc 1.1
> > driver
> > > > > and I see a lot of SELECT 1 statements that are running longer in
sql
> > > > > 2005 than in sql 2000. what are these select 1 statements?
> > > > >
> > > >
> > > > SELECT 1
> > > >
> > > > Is a query that returns a single row and a single column containing
the
> > > > value 1. It's extremely cheap, and probably being used as kind of
> > "ping"
> > > > from some application. It's such a cheap query that its cost is
> > probably
> > > > just background noise.
> > > >
> > > > David
> > >
>