Showing posts with label level. Show all posts
Showing posts with label level. Show all posts

Monday, March 26, 2012

problems exporting to excel

I have 2 levels of drill down. The first level does expand/collapse. The
second level, the details, do not get exported unless that section was
already open in the report. I am using Excel XP.
Any ideas?
Thanks.Normally, even the drill down isn´t checked the data will be exported to
excel. perhpas you disabled the function in excel for drilling down into the
data (on the left side there are + and - signs if you have something to
drill down)
Unfortunately my Excel on my machine and is asking for the corp.CD which is
sure don´t have, because I am on the move, so I can´t give you the exact
menu item to search for, but I gues google and the help file form Excel
should be your friend.
--
HTH, Jens Suessmeyer.
--
http://www.sqlserver2005.de
--
"scraejtp" <scraejtp@.discussions.microsoft.com> schrieb im Newsbeitrag
news:10F795EE-7C5C-4A80-9492-607216270F8D@.microsoft.com...
>I have 2 levels of drill down. The first level does expand/collapse. The
> second level, the details, do not get exported unless that section was
> already open in the report. I am using Excel XP.
> Any ideas?
> Thanks.|||If I expand one of the drill downs and then export it then it works fine. I
can use the +/- sign in excel on the second drill down, but if I leave both
collapsed when I export it then I can't.
"Jens Sü�meyer" wrote:
> Normally, even the drill down isn´t checked the data will be exported to
> excel. perhpas you disabled the function in excel for drilling down into the
> data (on the left side there are + and - signs if you have something to
> drill down)
> Unfortunately my Excel on my machine and is asking for the corp.CD which is
> sure don´t have, because I am on the move, so I can´t give you the exact
> menu item to search for, but I gues google and the help file form Excel
> should be your friend.
> --
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
> "scraejtp" <scraejtp@.discussions.microsoft.com> schrieb im Newsbeitrag
> news:10F795EE-7C5C-4A80-9492-607216270F8D@.microsoft.com...
> >I have 2 levels of drill down. The first level does expand/collapse. The
> > second level, the details, do not get exported unless that section was
> > already open in the report. I am using Excel XP.
> > Any ideas?
> > Thanks.
>
>|||I have the same issue and brought it up a month ago, but didn't receive any
responses. I'm not sure what to do about it. I did create a copy of the
report with everything expanded and may link that from my web page, but this
a kludge at best.
Neil
"scraejtp" wrote:
> I have 2 levels of drill down. The first level does expand/collapse. The
> second level, the details, do not get exported unless that section was
> already open in the report. I am using Excel XP.
> Any ideas?
> Thanks.|||Yes, I saw that thread. I actually did a copy/paste of your question because
I am having the exact same problem.
"Neil Gould" wrote:
> I have the same issue and brought it up a month ago, but didn't receive any
> responses. I'm not sure what to do about it. I did create a copy of the
> report with everything expanded and may link that from my web page, but this
> a kludge at best.
> Neil
> "scraejtp" wrote:
> > I have 2 levels of drill down. The first level does expand/collapse. The
> > second level, the details, do not get exported unless that section was
> > already open in the report. I am using Excel XP.
> > Any ideas?
> > Thanks.

Friday, March 23, 2012

Problems Defragging Indices (SQL2005 64-bit)

Hi all,
I have just migrated a database from SQL 2000 32 bit to SQL 2005 64 bit. I
also upgraded the compatability level to 9. Performance was immediately
horrible in terms of query execution.
Trying to solve the issue, I ran a query to retrieve indices with avgfrag >
10%. I then tried rebuilding the indices with ALTER INDEX, and ran my query
again. The avgfrag had NOT CHANGED.
What am I doing wrong?
While we're at it, I got several timeout errors from clients connecting with
ADO.NET from with the network. Their app's connection string specifies a
timeout of 120 sec, but they were timing out well before this. Just before
my database/server "upgrade", this was NOT happening. Where to best change
this to prevent further timeouts until I can get my indices and stats in
better shape?
Thanks.
John
Hi John
Have you checked local connectivity and connectivity from (say) query
analyser to the new server? Is remote access enabled?
When migrating did you trasfer logins/users correctly, do you have orphaned
users? Have you tried scripting/recreating the indexes, I would also consider
doing this for all views/stored procedures/functions also. Make sure that you
have updated the usage and statistics as well.
John
"JT" wrote:

> Hi all,
> I have just migrated a database from SQL 2000 32 bit to SQL 2005 64 bit. I
> also upgraded the compatability level to 9. Performance was immediately
> horrible in terms of query execution.
> Trying to solve the issue, I ran a query to retrieve indices with avgfrag >
> 10%. I then tried rebuilding the indices with ALTER INDEX, and ran my query
> again. The avgfrag had NOT CHANGED.
> What am I doing wrong?
> While we're at it, I got several timeout errors from clients connecting with
> ADO.NET from with the network. Their app's connection string specifies a
> timeout of 120 sec, but they were timing out well before this. Just before
> my database/server "upgrade", this was NOT happening. Where to best change
> this to prevent further timeouts until I can get my indices and stats in
> better shape?
> Thanks.
> --
> John
|||Hello John,
I understand that you tried to use "alter index ...rebuild all" statement
to some indexes, and its fragment is not changed. Also, you saw performance
degration after database migration to 2005 64 bit version from SQL 2000.
You encountered timout errors less than 120s from clients though connection
string specifies 120s. If I'm off base, please correct me.
Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
fragment information? Based on my experience, if a table does not include
clustered index, it may have large logical fragment and low density.
However, this does not necessarily indicate the tables/indexes are not
efficient for all queries. Generally, rebuild index for this situation does
not change the logical fragment value. You may consider use a different
fillfactor but I don't think this may be related to the performance issue
you encountered.
Also, does the issue occurs on some specific queries? Does 2 servers have
the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
of performance troubleshooting in 2005 is as following:
Troubleshooting Performance Problems in SQL Server 2005
http://www.microsoft.com/technet/pro.../tsprfprb.mspx
First, please install SP1 on the server if it is not installed since many
known issues are addressed in sp1.
you may want to update the statistics information by using "update
statistics" statment with "fullscan" option to see if it does any
difference. You may also want to change the compatability level to 80 to
test. On the other thand, if the old server exist, you may want to compare
the execution plan on both servers to see if there is any differences:
HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
http://support.microsoft.com/?id=243589
Please run sp_configure on both server to see if there is any difference.
You'd like to change "max degree of parallelism" to 1 if you have
mulitprocessors on the server to see the result.
As for tiemout issue, you may first check if the issue occurs on local
console of SQL Server if possible. Also, did you set commandtimeout or
connectiontimout? Usually commandtimeout might be cause of this issue of
long running quries.
http://msdn.microsoft.com/library/de...us/ado270/htm/
mdprocommandtimeout.asp
To isolate the client/server issue, you may want to install latest mdac and
sql native client on different machine, and make sure the issue occurs on
different clients
How to obtain the latest MDAC 2.8 service pack
http://support.microsoft.com/kb/884103/
http://www.microsoft.com/downloads/d...5AA-B4BD-4705-
AA0A-B477BA72A9CB&displaylang=en
If you isolate this to be a server side issue, you may want to check if you
encounter the following known issue and get fix from it to see if you
encoutnered the issue.
FIX: The internal deadlock monitor may not detect a deadlock between two or
more sessions in SQL Server 2005
http://support.microsoft.com/kb/915918
If you have any update, please feel free to let's know. Thank you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications
<http://msdn.microsoft.com/subscripti...s/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscripti...t/default.aspx>.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hello John,
I'm still interested in this issue. Did you try to solve the issue in the
weekend? If the issue persists, please get the informaiton I mentioend so
that we may further troubleshoot the issue. If you have other priorites,
please also let's know and we may work on the problem a little alter. Thank
you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====
|||Hi Peter,
I have largely resolved the issue. The steps I took included
1. greatly expanding the resources of tempdb, giving it eight equally sized
200MB mdf/ndf files to work with on a RAID 1/0 LUN.
2. Using NOEXPAND to force the optimizer to choose indexed views. (This
made a HUGE difference - like 1000% performance gains.) You can see my post
on this in SQL Server.Programming under Indexed View Issue, dated 11/22/2006).
3. Identifying an error in the 2005 scripting wizard which has been sending
me on a tail-chase regarding indices on Indexed Views. You can see my post
on this at SQL Server.Server under WARNING-SCRIPTING ENGINE UNRELIABLE, dated
11/26/2006.
4. Reading Itzak Ben-Gan's two books and doing a lot of optimization work.
Bottom line, I had a particularly gruesome query that ran in 7 seconds with
SQL 2000, and then went up to 25 seconds in SQL 2005 x64. I got it down to
1.7 seconds now, still using SQL 2005 x64. This is just one of many examples.
Thanks for your help.
John
"Peter Yang [MSFT]" wrote:

> Hello John,
> I'm still interested in this issue. Did you try to solve the issue in the
> weekend? If the issue persists, please get the informaiton I mentioend so
> that we may further troubleshoot the issue. If you have other priorites,
> please also let's know and we may work on the problem a little alter. Thank
> you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Partner Support
>
> ================================================== ===
> This posting is provided "AS IS" with no warranties, and confers no rights.
> ================================================== ====
>
>
|||Hi John
Thanks for the feed back,
Links to the previous threads:
2. Indexed View Issue http://tinyurl.com/yj4qvn
3. WARNING-SCRIPTING ENGINE UNRELIABLE - http://tinyurl.com/wu6aq
IMO Itzik's books in the Inside SQL Server 2005 series are must buys for any
Programmer/DBA using SQL Server 2005.
John
"JT" wrote:
[vbcol=seagreen]
> Hi Peter,
> I have largely resolved the issue. The steps I took included
> 1. greatly expanding the resources of tempdb, giving it eight equally sized
> 200MB mdf/ndf files to work with on a RAID 1/0 LUN.
> 2. Using NOEXPAND to force the optimizer to choose indexed views. (This
> made a HUGE difference - like 1000% performance gains.) You can see my post
> on this in SQL Server.Programming under Indexed View Issue, dated 11/22/2006).
> 3. Identifying an error in the 2005 scripting wizard which has been sending
> me on a tail-chase regarding indices on Indexed Views. You can see my post
> on this at SQL Server.Server under WARNING-SCRIPTING ENGINE UNRELIABLE, dated
> 11/26/2006.
> 4. Reading Itzak Ben-Gan's two books and doing a lot of optimization work.
> Bottom line, I had a particularly gruesome query that ran in 7 seconds with
> SQL 2000, and then went up to 25 seconds in SQL 2005 x64. I got it down to
> 1.7 seconds now, still using SQL 2005 x64. This is just one of many examples.
> Thanks for your help.
>
> --
> John
>
> "Peter Yang [MSFT]" wrote:
|||Hello John,
Thank you for sharing your experience on this issue and this shall
defenitely benefit the community. :-)
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====
sql

Problems Defragging Indices (SQL2005 64-bit)

Hi all,
I have just migrated a database from SQL 2000 32 bit to SQL 2005 64 bit. I
also upgraded the compatability level to 9. Performance was immediately
horrible in terms of query execution.
Trying to solve the issue, I ran a query to retrieve indices with avgfrag >
10%. I then tried rebuilding the indices with ALTER INDEX, and ran my query
again. The avgfrag had NOT CHANGED.
What am I doing wrong?
While we're at it, I got several timeout errors from clients connecting with
ADO.NET from with the network. Their app's connection string specifies a
timeout of 120 sec, but they were timing out well before this. Just before
my database/server "upgrade", this was NOT happening. Where to best change
this to prevent further timeouts until I can get my indices and stats in
better shape?
Thanks.
--
JohnHi John
Have you checked local connectivity and connectivity from (say) query
analyser to the new server? Is remote access enabled?
When migrating did you trasfer logins/users correctly, do you have orphaned
users? Have you tried scripting/recreating the indexes, I would also conside
r
doing this for all views/stored procedures/functions also. Make sure that yo
u
have updated the usage and statistics as well.
John
"JT" wrote:

> Hi all,
> I have just migrated a database from SQL 2000 32 bit to SQL 2005 64 bit.
I
> also upgraded the compatability level to 9. Performance was immediately
> horrible in terms of query execution.
> Trying to solve the issue, I ran a query to retrieve indices with avgfrag
> 10%. I then tried rebuilding the indices with ALTER INDEX, and ran my que
ry
> again. The avgfrag had NOT CHANGED.
> What am I doing wrong?
> While we're at it, I got several timeout errors from clients connecting wi
th
> ADO.NET from with the network. Their app's connection string specifies a
> timeout of 120 sec, but they were timing out well before this. Just befor
e
> my database/server "upgrade", this was NOT happening. Where to best chang
e
> this to prevent further timeouts until I can get my indices and stats in
> better shape?
> Thanks.
> --
> John|||Hello John,
I understand that you tried to use "alter index ...rebuild all" statement
to some indexes, and its fragment is not changed. Also, you saw performance
degration after database migration to 2005 64 bit version from SQL 2000.
You encountered timout errors less than 120s from clients though connection
string specifies 120s. If I'm off base, please correct me.
Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
fragment information? Based on my experience, if a table does not include
clustered index, it may have large logical fragment and low density.
However, this does not necessarily indicate the tables/indexes are not
efficient for all queries. Generally, rebuild index for this situation does
not change the logical fragment value. You may consider use a different
fillfactor but I don't think this may be related to the performance issue
you encountered.
Also, does the issue occurs on some specific queries? Does 2 servers have
the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
of performance troubleshooting in 2005 is as following:
Troubleshooting Performance Problems in SQL Server 2005
http://www.microsoft.com/technet/pr...5/tsprfprb.mspx
First, please install SP1 on the server if it is not installed since many
known issues are addressed in sp1.
you may want to update the statistics information by using "update
statistics" statment with "fullscan" option to see if it does any
difference. You may also want to change the compatability level to 80 to
test. On the other thand, if the old server exist, you may want to compare
the execution plan on both servers to see if there is any differences:
HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
http://support.microsoft.com/?id=243589
Please run sp_configure on both server to see if there is any difference.
You'd like to change "max degree of parallelism" to 1 if you have
mulitprocessors on the server to see the result.
As for tiemout issue, you may first check if the issue occurs on local
console of SQL Server if possible. Also, did you set commandtimeout or
connectiontimout? Usually commandtimeout might be cause of this issue of
long running quries.
http://msdn.microsoft.com/library/d...-us/ado270/htm/
mdprocommandtimeout.asp
To isolate the client/server issue, you may want to install latest mdac and
sql native client on different machine, and make sure the issue occurs on
different clients
How to obtain the latest MDAC 2.8 service pack
http://support.microsoft.com/kb/884103/
http://www.microsoft.com/downloads/...A5AA-B4BD-4705-
AA0A-B477BA72A9CB&displaylang=en
If you isolate this to be a server side issue, you may want to check if you
encounter the following known issue and get fix from it to see if you
encoutnered the issue.
FIX: The internal deadlock monitor may not detect a deadlock between two or
more sessions in SQL Server 2005
http://support.microsoft.com/kb/915918
If you have any update, please feel free to let's know. Thank you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
========================================
==========
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscript...ault.aspx#notif
ications
<http://msdn.microsoft.com/subscript...ps/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscript...rt/default.aspx>.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.|||Thank you John and Peter. The problem seems to be isolated to several
queries that rely on Indexed Views for their execution plan. The indices on
these Indexed Views really seem to be the problem. I was able to make quite
a bit of headway by disposing of several of the indices in these views, and
taking advantage of the new INCLUDE feature. Things still do not run as fas
t
(about 50% SLOWER) as they did on SQL 2000 32 bit, but at least I am no
longer getting the timeouts.
--
John
"Peter Yang [MSFT]" wrote:

> Hello John,
> I understand that you tried to use "alter index ...rebuild all" statement
> to some indexes, and its fragment is not changed. Also, you saw performanc
e
> degration after database migration to 2005 64 bit version from SQL 2000.
> You encountered timout errors less than 120s from clients though connectio
n
> string specifies 120s. If I'm off base, please correct me.
> Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
> fragment information? Based on my experience, if a table does not include
> clustered index, it may have large logical fragment and low density.
> However, this does not necessarily indicate the tables/indexes are not
> efficient for all queries. Generally, rebuild index for this situation doe
s
> not change the logical fragment value. You may consider use a different
> fillfactor but I don't think this may be related to the performance issue
> you encountered.
> Also, does the issue occurs on some specific queries? Does 2 servers have
> the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
> of performance troubleshooting in 2005 is as following:
> Troubleshooting Performance Problems in SQL Server 2005
> http://www.microsoft.com/technet/pr...5/tsprfprb.mspx
> First, please install SP1 on the server if it is not installed since many
> known issues are addressed in sp1.
> you may want to update the statistics information by using "update
> statistics" statment with "fullscan" option to see if it does any
> difference. You may also want to change the compatability level to 80 to
> test. On the other thand, if the old server exist, you may want to compare
> the execution plan on both servers to see if there is any differences:
> HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
> http://support.microsoft.com/?id=243589
> Please run sp_configure on both server to see if there is any difference.
> You'd like to change "max degree of parallelism" to 1 if you have
> mulitprocessors on the server to see the result.
> As for tiemout issue, you may first check if the issue occurs on local
> console of SQL Server if possible. Also, did you set commandtimeout or
> connectiontimout? Usually commandtimeout might be cause of this issue of
> long running quries.
> http://msdn.microsoft.com/library/d...com/kb/884103/
> http://www.microsoft.com/downloads/...t.com/kb/915918
> If you have any update, please feel free to let's know. Thank you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Community Support
> ========================================
==========
> Get notification to my posts through email? Please refer to
> l]
> ications
> <[url]http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx" target="_blank">http://msdn.microsoft.com/subscript...ps/default.aspx>.
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> <http://msdn.microsoft.com/subscript...rt/default.aspx>.
> ========================================
==========
> This posting is provided "AS IS" with no warranties, and confers no rights
.
>|||UNBELIEVABLE! Last night I had a particular problem sproc running in 15
seconds on my 2GB laptop with 64 bit CPU and SQL Server 2005 64 bit. I
drop/created the underlying indexed views on my 4 CPU XEON 3.3Ghz with 15k
discs DELL 6850, 15k SAN discs, separated mdfs, ldfs, and tempdb on RAID 1 o
r
RAID 10 production clustered setup, and the best I can get is 45 seconds wit
h
the same procedure. This is even after a full stats update and index
rebuilding. What am I doing wrong? This occurs whether am I running from a
remote client, or locally on the host node. The databases are the same, as
is the underlying data.
John
"Peter Yang [MSFT]" wrote:

> Hello John,
> I understand that you tried to use "alter index ...rebuild all" statement
> to some indexes, and its fragment is not changed. Also, you saw performanc
e
> degration after database migration to 2005 64 bit version from SQL 2000.
> You encountered timout errors less than 120s from clients though connectio
n
> string specifies 120s. If I'm off base, please correct me.
> Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
> fragment information? Based on my experience, if a table does not include
> clustered index, it may have large logical fragment and low density.
> However, this does not necessarily indicate the tables/indexes are not
> efficient for all queries. Generally, rebuild index for this situation doe
s
> not change the logical fragment value. You may consider use a different
> fillfactor but I don't think this may be related to the performance issue
> you encountered.
> Also, does the issue occurs on some specific queries? Does 2 servers have
> the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
> of performance troubleshooting in 2005 is as following:
> Troubleshooting Performance Problems in SQL Server 2005
> http://www.microsoft.com/technet/pr...5/tsprfprb.mspx
> First, please install SP1 on the server if it is not installed since many
> known issues are addressed in sp1.
> you may want to update the statistics information by using "update
> statistics" statment with "fullscan" option to see if it does any
> difference. You may also want to change the compatability level to 80 to
> test. On the other thand, if the old server exist, you may want to compare
> the execution plan on both servers to see if there is any differences:
> HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
> http://support.microsoft.com/?id=243589
> Please run sp_configure on both server to see if there is any difference.
> You'd like to change "max degree of parallelism" to 1 if you have
> mulitprocessors on the server to see the result.
> As for tiemout issue, you may first check if the issue occurs on local
> console of SQL Server if possible. Also, did you set commandtimeout or
> connectiontimout? Usually commandtimeout might be cause of this issue of
> long running quries.
> http://msdn.microsoft.com/library/d...com/kb/884103/
> http://www.microsoft.com/downloads/...t.com/kb/915918
> If you have any update, please feel free to let's know. Thank you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Community Support
> ========================================
==========
> Get notification to my posts through email? Please refer to
> l]
> ications
> <[url]http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx" target="_blank">http://msdn.microsoft.com/subscript...ps/default.aspx>.
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> <http://msdn.microsoft.com/subscript...rt/default.aspx>.
> ========================================
==========
> This posting is provided "AS IS" with no warranties, and confers no rights
.
>|||Same execution plan?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"JT" <Jthayer@.online.nospam> wrote in message
news:E3A82D97-5063-4803-8B5E-2C1B6AD3BCCA@.microsoft.com...[vbcol=seagreen]
> UNBELIEVABLE! Last night I had a particular problem sproc running in 15
> seconds on my 2GB laptop with 64 bit CPU and SQL Server 2005 64 bit. I
> drop/created the underlying indexed views on my 4 CPU XEON 3.3Ghz with 15k
> discs DELL 6850, 15k SAN discs, separated mdfs, ldfs, and tempdb on RAID 1
or
> RAID 10 production clustered setup, and the best I can get is 45 seconds w
ith
> the same procedure. This is even after a full stats update and index
> rebuilding. What am I doing wrong? This occurs whether am I running from
a
> remote client, or locally on the host node. The databases are the same, a
s
> is the underlying data.
> --
> John
>
> "Peter Yang [MSFT]" wrote:
>|||Hi Tibor,
Approximately so, but not fully investigated as these are quite complicated
queries that go way off the page when displaying the exec plan.
One thing I am noticing as I investigate these indices...
When I use SSMS to examine the indices of this database sitting on a SQL
2000 instance, I have no options for Use RowLocks and Use Page Locks when
accessing the index (as expected). When I examine the same database after
migration to SQL 2005 (via forced restore), I see the same indices with both
of these options checked. Could it be helpful to go through and uncheck
these boxes? Is there some way to do this en masse? Thanks.
--
John
"Tibor Karaszi" wrote:

> Same execution plan?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "JT" <Jthayer@.online.nospam> wrote in message
> news:E3A82D97-5063-4803-8B5E-2C1B6AD3BCCA@.microsoft.com...
>|||The "allow row locks" and "allow page locks" option is available on earlier
versions as well (I
believe since 6.5). In 2005, you set the option using CREATE and ALTER INDEX
, in earlier versions
you set it through sp_indexoption. Default is to allow both page and row loc
ks. So I very much doubt
that this is the issue here.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"JT" <Jthayer@.online.nospam> wrote in message
news:51197459-F3F5-40BC-9A53-9AC2C3080C0D@.microsoft.com...[vbcol=seagreen]
> Hi Tibor,
> Approximately so, but not fully investigated as these are quite complicate
d
> queries that go way off the page when displaying the exec plan.
> One thing I am noticing as I investigate these indices...
> When I use SSMS to examine the indices of this database sitting on a SQL
> 2000 instance, I have no options for Use RowLocks and Use Page Locks when
> accessing the index (as expected). When I examine the same database after
> migration to SQL 2005 (via forced restore), I see the same indices with bo
th
> of these options checked. Could it be helpful to go through and uncheck
> these boxes? Is there some way to do this en masse? Thanks.
> --
> John
>
> "Tibor Karaszi" wrote:
>|||Hello John,
By default, the optioins are checked and isually it is not recommended to
uncheck "use row locks" and "use page locks" for the indexes. SQL Server
shall select row locks/page locks for the better performance for specific
queries. For example, for operations that only relates several rows, it is
not efficient to only allow page locks. However, you may try to uncheck
this to see if there is any difference.
First, as Tibor mentioned, you may compare the exectution plans of both
servers to make sure it is exact same. If it is same, you may try the
following steps to get the exact
DBCC TRACEON (8760, 8605, 8606, 8607)
SET STATISTICS PROFILE ON
SET STATISTICS TIME ON
SET STATISTICS IO ON
dbcc freeproccache
dbcc dropcleanbuffers
Go
--Exec <place your stored procedure or query here>
go
SET STATISTICS PROFILE OFF
SET STATISTICS TIME OFF
SET STATISTICS IO OFF
DBCC TRACEOFF (8760, 8605, 8606, 8607)
go
Please save the result execution plan in CSV file, and copy the io/cpu/time
information in message window to a file, and send them to me at
petery@.microsoft.com.
In addtion, I'd like to know if the cluster server is a production server
under heavy load. You may use perfmon to check if there is any memory/iO
pressure on the server. Usually on a heavy load server, it is possible that
a query might be slower than a server without other loads.
http://www.extremeexperts.com/SQL/A...QLCounters.aspx
If query execution plan is different, it might be related to the following
- The metadata of the tables used in the query (columns, indexes,
constraints, indexed views, etc)
- The size of the tables and other physical structures (number of rows,
pages)
- statistics (created at some point in time in the past over the data in
the tables)
- The MAXDOP setting
- The amount of memory on the machine
- Session settings (ANSI_NULLs, etc)
- Difference in server engine
You may want to check above to see if there is any difference. If the query
is related to index view, you may want to tempoarily drop the view on both
servers to test the situation.
If you have any update, please feel free to let's know. Thank you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
========================================
==============|||Hi John,
I've also experienced the drop in performance when going from SQL 2000 32
Bit to SQL 2005 64 Bit. After a lot of tuning I got it back to the same
performance as in SQL 2000, but this includes rewriting a lot of queries. It
seems that the query optimizer is working totally different than in SQL
2000. Complex derived tables and subqueries with inner subqueries are good
candidates for rewriting.
So much work to get the same speed.
Kay

Problems Defragging Indices (SQL2005 64-bit)

Hi all,
I have just migrated a database from SQL 2000 32 bit to SQL 2005 64 bit. I
also upgraded the compatability level to 9. Performance was immediately
horrible in terms of query execution.
Trying to solve the issue, I ran a query to retrieve indices with avgfrag >
10%. I then tried rebuilding the indices with ALTER INDEX, and ran my query
again. The avgfrag had NOT CHANGED.
What am I doing wrong?
While we're at it, I got several timeout errors from clients connecting with
ADO.NET from with the network. Their app's connection string specifies a
timeout of 120 sec, but they were timing out well before this. Just before
my database/server "upgrade", this was NOT happening. Where to best change
this to prevent further timeouts until I can get my indices and stats in
better shape?
Thanks.
--
JohnHi John
Have you checked local connectivity and connectivity from (say) query
analyser to the new server? Is remote access enabled?
When migrating did you trasfer logins/users correctly, do you have orphaned
users? Have you tried scripting/recreating the indexes, I would also consider
doing this for all views/stored procedures/functions also. Make sure that you
have updated the usage and statistics as well.
John
"JT" wrote:
> Hi all,
> I have just migrated a database from SQL 2000 32 bit to SQL 2005 64 bit. I
> also upgraded the compatability level to 9. Performance was immediately
> horrible in terms of query execution.
> Trying to solve the issue, I ran a query to retrieve indices with avgfrag >
> 10%. I then tried rebuilding the indices with ALTER INDEX, and ran my query
> again. The avgfrag had NOT CHANGED.
> What am I doing wrong?
> While we're at it, I got several timeout errors from clients connecting with
> ADO.NET from with the network. Their app's connection string specifies a
> timeout of 120 sec, but they were timing out well before this. Just before
> my database/server "upgrade", this was NOT happening. Where to best change
> this to prevent further timeouts until I can get my indices and stats in
> better shape?
> Thanks.
> --
> John|||Hello John,
I understand that you tried to use "alter index ...rebuild all" statement
to some indexes, and its fragment is not changed. Also, you saw performance
degration after database migration to 2005 64 bit version from SQL 2000.
You encountered timout errors less than 120s from clients though connection
string specifies 120s. If I'm off base, please correct me.
Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
fragment information? Based on my experience, if a table does not include
clustered index, it may have large logical fragment and low density.
However, this does not necessarily indicate the tables/indexes are not
efficient for all queries. Generally, rebuild index for this situation does
not change the logical fragment value. You may consider use a different
fillfactor but I don't think this may be related to the performance issue
you encountered.
Also, does the issue occurs on some specific queries? Does 2 servers have
the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
of performance troubleshooting in 2005 is as following:
Troubleshooting Performance Problems in SQL Server 2005
http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
First, please install SP1 on the server if it is not installed since many
known issues are addressed in sp1.
you may want to update the statistics information by using "update
statistics" statment with "fullscan" option to see if it does any
difference. You may also want to change the compatability level to 80 to
test. On the other thand, if the old server exist, you may want to compare
the execution plan on both servers to see if there is any differences:
HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
http://support.microsoft.com/?id=243589
Please run sp_configure on both server to see if there is any difference.
You'd like to change "max degree of parallelism" to 1 if you have
mulitprocessors on the server to see the result.
As for tiemout issue, you may first check if the issue occurs on local
console of SQL Server if possible. Also, did you set commandtimeout or
connectiontimout? Usually commandtimeout might be cause of this issue of
long running quries.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/
mdprocommandtimeout.asp
To isolate the client/server issue, you may want to install latest mdac and
sql native client on different machine, and make sure the issue occurs on
different clients
How to obtain the latest MDAC 2.8 service pack
http://support.microsoft.com/kb/884103/
http://www.microsoft.com/downloads/details.aspx?familyid=DF0BA5AA-B4BD-4705-
AA0A-B477BA72A9CB&displaylang=en
If you isolate this to be a server side issue, you may want to check if you
encounter the following known issue and get fix from it to see if you
encoutnered the issue.
FIX: The internal deadlock monitor may not detect a deadlock between two or
more sessions in SQL Server 2005
http://support.microsoft.com/kb/915918
If you have any update, please feel free to let's know. Thank you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
==================================================Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
<http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscriptions/support/default.aspx>.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Thank you John and Peter. The problem seems to be isolated to several
queries that rely on Indexed Views for their execution plan. The indices on
these Indexed Views really seem to be the problem. I was able to make quite
a bit of headway by disposing of several of the indices in these views, and
taking advantage of the new INCLUDE feature. Things still do not run as fast
(about 50% SLOWER) as they did on SQL 2000 32 bit, but at least I am no
longer getting the timeouts.
--
John
"Peter Yang [MSFT]" wrote:
> Hello John,
> I understand that you tried to use "alter index ...rebuild all" statement
> to some indexes, and its fragment is not changed. Also, you saw performance
> degration after database migration to 2005 64 bit version from SQL 2000.
> You encountered timout errors less than 120s from clients though connection
> string specifies 120s. If I'm off base, please correct me.
> Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
> fragment information? Based on my experience, if a table does not include
> clustered index, it may have large logical fragment and low density.
> However, this does not necessarily indicate the tables/indexes are not
> efficient for all queries. Generally, rebuild index for this situation does
> not change the logical fragment value. You may consider use a different
> fillfactor but I don't think this may be related to the performance issue
> you encountered.
> Also, does the issue occurs on some specific queries? Does 2 servers have
> the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
> of performance troubleshooting in 2005 is as following:
> Troubleshooting Performance Problems in SQL Server 2005
> http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
> First, please install SP1 on the server if it is not installed since many
> known issues are addressed in sp1.
> you may want to update the statistics information by using "update
> statistics" statment with "fullscan" option to see if it does any
> difference. You may also want to change the compatability level to 80 to
> test. On the other thand, if the old server exist, you may want to compare
> the execution plan on both servers to see if there is any differences:
> HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
> http://support.microsoft.com/?id=243589
> Please run sp_configure on both server to see if there is any difference.
> You'd like to change "max degree of parallelism" to 1 if you have
> mulitprocessors on the server to see the result.
> As for tiemout issue, you may first check if the issue occurs on local
> console of SQL Server if possible. Also, did you set commandtimeout or
> connectiontimout? Usually commandtimeout might be cause of this issue of
> long running quries.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/
> mdprocommandtimeout.asp
> To isolate the client/server issue, you may want to install latest mdac and
> sql native client on different machine, and make sure the issue occurs on
> different clients
> How to obtain the latest MDAC 2.8 service pack
> http://support.microsoft.com/kb/884103/
> http://www.microsoft.com/downloads/details.aspx?familyid=DF0BA5AA-B4BD-4705-
> AA0A-B477BA72A9CB&displaylang=en
> If you isolate this to be a server side issue, you may want to check if you
> encounter the following known issue and get fix from it to see if you
> encoutnered the issue.
> FIX: The internal deadlock monitor may not detect a deadlock between two or
> more sessions in SQL Server 2005
> http://support.microsoft.com/kb/915918
> If you have any update, please feel free to let's know. Thank you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Community Support
> ==================================================> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications
> <http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> <http://msdn.microsoft.com/subscriptions/support/default.aspx>.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||UNBELIEVABLE! Last night I had a particular problem sproc running in 15
seconds on my 2GB laptop with 64 bit CPU and SQL Server 2005 64 bit. I
drop/created the underlying indexed views on my 4 CPU XEON 3.3Ghz with 15k
discs DELL 6850, 15k SAN discs, separated mdfs, ldfs, and tempdb on RAID 1 or
RAID 10 production clustered setup, and the best I can get is 45 seconds with
the same procedure. This is even after a full stats update and index
rebuilding. What am I doing wrong? This occurs whether am I running from a
remote client, or locally on the host node. The databases are the same, as
is the underlying data.
--
John
"Peter Yang [MSFT]" wrote:
> Hello John,
> I understand that you tried to use "alter index ...rebuild all" statement
> to some indexes, and its fragment is not changed. Also, you saw performance
> degration after database migration to 2005 64 bit version from SQL 2000.
> You encountered timout errors less than 120s from clients though connection
> string specifies 120s. If I'm off base, please correct me.
> Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
> fragment information? Based on my experience, if a table does not include
> clustered index, it may have large logical fragment and low density.
> However, this does not necessarily indicate the tables/indexes are not
> efficient for all queries. Generally, rebuild index for this situation does
> not change the logical fragment value. You may consider use a different
> fillfactor but I don't think this may be related to the performance issue
> you encountered.
> Also, does the issue occurs on some specific queries? Does 2 servers have
> the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
> of performance troubleshooting in 2005 is as following:
> Troubleshooting Performance Problems in SQL Server 2005
> http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
> First, please install SP1 on the server if it is not installed since many
> known issues are addressed in sp1.
> you may want to update the statistics information by using "update
> statistics" statment with "fullscan" option to see if it does any
> difference. You may also want to change the compatability level to 80 to
> test. On the other thand, if the old server exist, you may want to compare
> the execution plan on both servers to see if there is any differences:
> HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
> http://support.microsoft.com/?id=243589
> Please run sp_configure on both server to see if there is any difference.
> You'd like to change "max degree of parallelism" to 1 if you have
> mulitprocessors on the server to see the result.
> As for tiemout issue, you may first check if the issue occurs on local
> console of SQL Server if possible. Also, did you set commandtimeout or
> connectiontimout? Usually commandtimeout might be cause of this issue of
> long running quries.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/
> mdprocommandtimeout.asp
> To isolate the client/server issue, you may want to install latest mdac and
> sql native client on different machine, and make sure the issue occurs on
> different clients
> How to obtain the latest MDAC 2.8 service pack
> http://support.microsoft.com/kb/884103/
> http://www.microsoft.com/downloads/details.aspx?familyid=DF0BA5AA-B4BD-4705-
> AA0A-B477BA72A9CB&displaylang=en
> If you isolate this to be a server side issue, you may want to check if you
> encounter the following known issue and get fix from it to see if you
> encoutnered the issue.
> FIX: The internal deadlock monitor may not detect a deadlock between two or
> more sessions in SQL Server 2005
> http://support.microsoft.com/kb/915918
> If you have any update, please feel free to let's know. Thank you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Community Support
> ==================================================> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications
> <http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> <http://msdn.microsoft.com/subscriptions/support/default.aspx>.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||Same execution plan?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"JT" <Jthayer@.online.nospam> wrote in message
news:E3A82D97-5063-4803-8B5E-2C1B6AD3BCCA@.microsoft.com...
> UNBELIEVABLE! Last night I had a particular problem sproc running in 15
> seconds on my 2GB laptop with 64 bit CPU and SQL Server 2005 64 bit. I
> drop/created the underlying indexed views on my 4 CPU XEON 3.3Ghz with 15k
> discs DELL 6850, 15k SAN discs, separated mdfs, ldfs, and tempdb on RAID 1 or
> RAID 10 production clustered setup, and the best I can get is 45 seconds with
> the same procedure. This is even after a full stats update and index
> rebuilding. What am I doing wrong? This occurs whether am I running from a
> remote client, or locally on the host node. The databases are the same, as
> is the underlying data.
> --
> John
>
> "Peter Yang [MSFT]" wrote:
>> Hello John,
>> I understand that you tried to use "alter index ...rebuild all" statement
>> to some indexes, and its fragment is not changed. Also, you saw performance
>> degration after database migration to 2005 64 bit version from SQL 2000.
>> You encountered timout errors less than 120s from clients though connection
>> string specifies 120s. If I'm off base, please correct me.
>> Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
>> fragment information? Based on my experience, if a table does not include
>> clustered index, it may have large logical fragment and low density.
>> However, this does not necessarily indicate the tables/indexes are not
>> efficient for all queries. Generally, rebuild index for this situation does
>> not change the logical fragment value. You may consider use a different
>> fillfactor but I don't think this may be related to the performance issue
>> you encountered.
>> Also, does the issue occurs on some specific queries? Does 2 servers have
>> the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
>> of performance troubleshooting in 2005 is as following:
>> Troubleshooting Performance Problems in SQL Server 2005
>> http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
>> First, please install SP1 on the server if it is not installed since many
>> known issues are addressed in sp1.
>> you may want to update the statistics information by using "update
>> statistics" statment with "fullscan" option to see if it does any
>> difference. You may also want to change the compatability level to 80 to
>> test. On the other thand, if the old server exist, you may want to compare
>> the execution plan on both servers to see if there is any differences:
>> HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
>> http://support.microsoft.com/?id=243589
>> Please run sp_configure on both server to see if there is any difference.
>> You'd like to change "max degree of parallelism" to 1 if you have
>> mulitprocessors on the server to see the result.
>> As for tiemout issue, you may first check if the issue occurs on local
>> console of SQL Server if possible. Also, did you set commandtimeout or
>> connectiontimout? Usually commandtimeout might be cause of this issue of
>> long running quries.
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/
>> mdprocommandtimeout.asp
>> To isolate the client/server issue, you may want to install latest mdac and
>> sql native client on different machine, and make sure the issue occurs on
>> different clients
>> How to obtain the latest MDAC 2.8 service pack
>> http://support.microsoft.com/kb/884103/
>> http://www.microsoft.com/downloads/details.aspx?familyid=DF0BA5AA-B4BD-4705-
>> AA0A-B477BA72A9CB&displaylang=en
>> If you isolate this to be a server side issue, you may want to check if you
>> encounter the following known issue and get fix from it to see if you
>> encoutnered the issue.
>> FIX: The internal deadlock monitor may not detect a deadlock between two or
>> more sessions in SQL Server 2005
>> http://support.microsoft.com/kb/915918
>> If you have any update, please feel free to let's know. Thank you.
>> Best Regards,
>> Peter Yang
>> MCSE2000/2003, MCSA, MCDBA
>> Microsoft Online Community Support
>> ==================================================>> Get notification to my posts through email? Please refer to
>> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
>> ications
>> <http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
>> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
>> where an initial response from the community or a Microsoft Support
>> Engineer within 1 business day is acceptable. Please note that each follow
>> up response may take approximately 2 business days as the support
>> professional working with you may need further investigation to reach the
>> most efficient resolution. The offering is not appropriate for situations
>> that require urgent, real-time or phone-based interactions or complex
>> project analysis and dump analysis issues. Issues of this nature are best
>> handled working with a dedicated Microsoft Support Engineer by contacting
>> Microsoft Customer Support Services (CSS) at
>> <http://msdn.microsoft.com/subscriptions/support/default.aspx>.
>> ==================================================>> This posting is provided "AS IS" with no warranties, and confers no rights.
>>|||Hi Tibor,
Approximately so, but not fully investigated as these are quite complicated
queries that go way off the page when displaying the exec plan.
One thing I am noticing as I investigate these indices...
When I use SSMS to examine the indices of this database sitting on a SQL
2000 instance, I have no options for Use RowLocks and Use Page Locks when
accessing the index (as expected). When I examine the same database after
migration to SQL 2005 (via forced restore), I see the same indices with both
of these options checked. Could it be helpful to go through and uncheck
these boxes? Is there some way to do this en masse? Thanks.
--
John
"Tibor Karaszi" wrote:
> Same execution plan?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "JT" <Jthayer@.online.nospam> wrote in message
> news:E3A82D97-5063-4803-8B5E-2C1B6AD3BCCA@.microsoft.com...
> > UNBELIEVABLE! Last night I had a particular problem sproc running in 15
> > seconds on my 2GB laptop with 64 bit CPU and SQL Server 2005 64 bit. I
> > drop/created the underlying indexed views on my 4 CPU XEON 3.3Ghz with 15k
> > discs DELL 6850, 15k SAN discs, separated mdfs, ldfs, and tempdb on RAID 1 or
> > RAID 10 production clustered setup, and the best I can get is 45 seconds with
> > the same procedure. This is even after a full stats update and index
> > rebuilding. What am I doing wrong? This occurs whether am I running from a
> > remote client, or locally on the host node. The databases are the same, as
> > is the underlying data.
> >
> > --
> > John
> >
> >
> > "Peter Yang [MSFT]" wrote:
> >
> >> Hello John,
> >>
> >> I understand that you tried to use "alter index ...rebuild all" statement
> >> to some indexes, and its fragment is not changed. Also, you saw performance
> >> degration after database migration to 2005 64 bit version from SQL 2000.
> >> You encountered timout errors less than 120s from clients though connection
> >> string specifies 120s. If I'm off base, please correct me.
> >>
> >> Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
> >> fragment information? Based on my experience, if a table does not include
> >> clustered index, it may have large logical fragment and low density.
> >> However, this does not necessarily indicate the tables/indexes are not
> >> efficient for all queries. Generally, rebuild index for this situation does
> >> not change the logical fragment value. You may consider use a different
> >> fillfactor but I don't think this may be related to the performance issue
> >> you encountered.
> >>
> >> Also, does the issue occurs on some specific queries? Does 2 servers have
> >> the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
> >> of performance troubleshooting in 2005 is as following:
> >>
> >> Troubleshooting Performance Problems in SQL Server 2005
> >> http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
> >>
> >> First, please install SP1 on the server if it is not installed since many
> >> known issues are addressed in sp1.
> >>
> >> you may want to update the statistics information by using "update
> >> statistics" statment with "fullscan" option to see if it does any
> >> difference. You may also want to change the compatability level to 80 to
> >> test. On the other thand, if the old server exist, you may want to compare
> >> the execution plan on both servers to see if there is any differences:
> >>
> >> HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
> >> http://support.microsoft.com/?id=243589
> >>
> >> Please run sp_configure on both server to see if there is any difference.
> >> You'd like to change "max degree of parallelism" to 1 if you have
> >> mulitprocessors on the server to see the result.
> >>
> >> As for tiemout issue, you may first check if the issue occurs on local
> >> console of SQL Server if possible. Also, did you set commandtimeout or
> >> connectiontimout? Usually commandtimeout might be cause of this issue of
> >> long running quries.
> >>
> >> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/
> >> mdprocommandtimeout.asp
> >>
> >> To isolate the client/server issue, you may want to install latest mdac and
> >> sql native client on different machine, and make sure the issue occurs on
> >> different clients
> >>
> >> How to obtain the latest MDAC 2.8 service pack
> >> http://support.microsoft.com/kb/884103/
> >>
> >> http://www.microsoft.com/downloads/details.aspx?familyid=DF0BA5AA-B4BD-4705-
> >> AA0A-B477BA72A9CB&displaylang=en
> >>
> >> If you isolate this to be a server side issue, you may want to check if you
> >> encounter the following known issue and get fix from it to see if you
> >> encoutnered the issue.
> >>
> >> FIX: The internal deadlock monitor may not detect a deadlock between two or
> >> more sessions in SQL Server 2005
> >> http://support.microsoft.com/kb/915918
> >>
> >> If you have any update, please feel free to let's know. Thank you.
> >>
> >> Best Regards,
> >>
> >> Peter Yang
> >> MCSE2000/2003, MCSA, MCDBA
> >> Microsoft Online Community Support
> >> ==================================================> >> Get notification to my posts through email? Please refer to
> >> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> >> ications
> >> <http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
> >> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> >> where an initial response from the community or a Microsoft Support
> >> Engineer within 1 business day is acceptable. Please note that each follow
> >> up response may take approximately 2 business days as the support
> >> professional working with you may need further investigation to reach the
> >> most efficient resolution. The offering is not appropriate for situations
> >> that require urgent, real-time or phone-based interactions or complex
> >> project analysis and dump analysis issues. Issues of this nature are best
> >> handled working with a dedicated Microsoft Support Engineer by contacting
> >> Microsoft Customer Support Services (CSS) at
> >> <http://msdn.microsoft.com/subscriptions/support/default.aspx>.
> >> ==================================================> >> This posting is provided "AS IS" with no warranties, and confers no rights.
> >>
> >>
>|||The "allow row locks" and "allow page locks" option is available on earlier versions as well (I
believe since 6.5). In 2005, you set the option using CREATE and ALTER INDEX, in earlier versions
you set it through sp_indexoption. Default is to allow both page and row locks. So I very much doubt
that this is the issue here.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"JT" <Jthayer@.online.nospam> wrote in message
news:51197459-F3F5-40BC-9A53-9AC2C3080C0D@.microsoft.com...
> Hi Tibor,
> Approximately so, but not fully investigated as these are quite complicated
> queries that go way off the page when displaying the exec plan.
> One thing I am noticing as I investigate these indices...
> When I use SSMS to examine the indices of this database sitting on a SQL
> 2000 instance, I have no options for Use RowLocks and Use Page Locks when
> accessing the index (as expected). When I examine the same database after
> migration to SQL 2005 (via forced restore), I see the same indices with both
> of these options checked. Could it be helpful to go through and uncheck
> these boxes? Is there some way to do this en masse? Thanks.
> --
> John
>
> "Tibor Karaszi" wrote:
>> Same execution plan?
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "JT" <Jthayer@.online.nospam> wrote in message
>> news:E3A82D97-5063-4803-8B5E-2C1B6AD3BCCA@.microsoft.com...
>> > UNBELIEVABLE! Last night I had a particular problem sproc running in 15
>> > seconds on my 2GB laptop with 64 bit CPU and SQL Server 2005 64 bit. I
>> > drop/created the underlying indexed views on my 4 CPU XEON 3.3Ghz with 15k
>> > discs DELL 6850, 15k SAN discs, separated mdfs, ldfs, and tempdb on RAID 1 or
>> > RAID 10 production clustered setup, and the best I can get is 45 seconds with
>> > the same procedure. This is even after a full stats update and index
>> > rebuilding. What am I doing wrong? This occurs whether am I running from a
>> > remote client, or locally on the host node. The databases are the same, as
>> > is the underlying data.
>> >
>> > --
>> > John
>> >
>> >
>> > "Peter Yang [MSFT]" wrote:
>> >
>> >> Hello John,
>> >>
>> >> I understand that you tried to use "alter index ...rebuild all" statement
>> >> to some indexes, and its fragment is not changed. Also, you saw performance
>> >> degration after database migration to 2005 64 bit version from SQL 2000.
>> >> You encountered timout errors less than 120s from clients though connection
>> >> string specifies 120s. If I'm off base, please correct me.
>> >>
>> >> Did you use sys.dm_db_index_physical_stats or dbcc showcontig to get the
>> >> fragment information? Based on my experience, if a table does not include
>> >> clustered index, it may have large logical fragment and low density.
>> >> However, this does not necessarily indicate the tables/indexes are not
>> >> efficient for all queries. Generally, rebuild index for this situation does
>> >> not change the logical fragment value. You may consider use a different
>> >> fillfactor but I don't think this may be related to the performance issue
>> >> you encountered.
>> >>
>> >> Also, does the issue occurs on some specific queries? Does 2 servers have
>> >> the same load? Did you see any bottleneck in memory/IO/CPU? The whitepaper
>> >> of performance troubleshooting in 2005 is as following:
>> >>
>> >> Troubleshooting Performance Problems in SQL Server 2005
>> >> http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
>> >>
>> >> First, please install SP1 on the server if it is not installed since many
>> >> known issues are addressed in sp1.
>> >>
>> >> you may want to update the statistics information by using "update
>> >> statistics" statment with "fullscan" option to see if it does any
>> >> difference. You may also want to change the compatability level to 80 to
>> >> test. On the other thand, if the old server exist, you may want to compare
>> >> the execution plan on both servers to see if there is any differences:
>> >>
>> >> HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later
>> >> http://support.microsoft.com/?id=243589
>> >>
>> >> Please run sp_configure on both server to see if there is any difference.
>> >> You'd like to change "max degree of parallelism" to 1 if you have
>> >> mulitprocessors on the server to see the result.
>> >>
>> >> As for tiemout issue, you may first check if the issue occurs on local
>> >> console of SQL Server if possible. Also, did you set commandtimeout or
>> >> connectiontimout? Usually commandtimeout might be cause of this issue of
>> >> long running quries.
>> >>
>> >> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/
>> >> mdprocommandtimeout.asp
>> >>
>> >> To isolate the client/server issue, you may want to install latest mdac and
>> >> sql native client on different machine, and make sure the issue occurs on
>> >> different clients
>> >>
>> >> How to obtain the latest MDAC 2.8 service pack
>> >> http://support.microsoft.com/kb/884103/
>> >>
>> >> http://www.microsoft.com/downloads/details.aspx?familyid=DF0BA5AA-B4BD-4705-
>> >> AA0A-B477BA72A9CB&displaylang=en
>> >>
>> >> If you isolate this to be a server side issue, you may want to check if you
>> >> encounter the following known issue and get fix from it to see if you
>> >> encoutnered the issue.
>> >>
>> >> FIX: The internal deadlock monitor may not detect a deadlock between two or
>> >> more sessions in SQL Server 2005
>> >> http://support.microsoft.com/kb/915918
>> >>
>> >> If you have any update, please feel free to let's know. Thank you.
>> >>
>> >> Best Regards,
>> >>
>> >> Peter Yang
>> >> MCSE2000/2003, MCSA, MCDBA
>> >> Microsoft Online Community Support
>> >> ==================================================>> >> Get notification to my posts through email? Please refer to
>> >> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
>> >> ications
>> >> <http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
>> >> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
>> >> where an initial response from the community or a Microsoft Support
>> >> Engineer within 1 business day is acceptable. Please note that each follow
>> >> up response may take approximately 2 business days as the support
>> >> professional working with you may need further investigation to reach the
>> >> most efficient resolution. The offering is not appropriate for situations
>> >> that require urgent, real-time or phone-based interactions or complex
>> >> project analysis and dump analysis issues. Issues of this nature are best
>> >> handled working with a dedicated Microsoft Support Engineer by contacting
>> >> Microsoft Customer Support Services (CSS) at
>> >> <http://msdn.microsoft.com/subscriptions/support/default.aspx>.
>> >> ==================================================>> >> This posting is provided "AS IS" with no warranties, and confers no rights.
>> >>
>> >>
>>|||Hello John,
By default, the optioins are checked and isually it is not recommended to
uncheck "use row locks" and "use page locks" for the indexes. SQL Server
shall select row locks/page locks for the better performance for specific
queries. For example, for operations that only relates several rows, it is
not efficient to only allow page locks. However, you may try to uncheck
this to see if there is any difference.
First, as Tibor mentioned, you may compare the exectution plans of both
servers to make sure it is exact same. If it is same, you may try the
following steps to get the exact
DBCC TRACEON (8760, 8605, 8606, 8607)
SET STATISTICS PROFILE ON
SET STATISTICS TIME ON
SET STATISTICS IO ON
dbcc freeproccache
dbcc dropcleanbuffers
Go
--Exec <place your stored procedure or query here>
go
SET STATISTICS PROFILE OFF
SET STATISTICS TIME OFF
SET STATISTICS IO OFF
DBCC TRACEOFF (8760, 8605, 8606, 8607)
go
Please save the result execution plan in CSV file, and copy the io/cpu/time
information in message window to a file, and send them to me at
petery@.microsoft.com.
In addtion, I'd like to know if the cluster server is a production server
under heavy load. You may use perfmon to check if there is any memory/iO
pressure on the server. Usually on a heavy load server, it is possible that
a query might be slower than a server without other loads.
http://www.extremeexperts.com/SQL/Articles/SQLCounters.aspx
If query execution plan is different, it might be related to the following
- The metadata of the tables used in the query (columns, indexes,
constraints, indexed views, etc)
- The size of the tables and other physical structures (number of rows,
pages)
- statistics (created at some point in time in the past over the data in
the tables)
- The MAXDOP setting
- The amount of memory on the machine
- Session settings (ANSI_NULLs, etc)
- Difference in server engine
You may want to check above to see if there is any difference. If the query
is related to index view, you may want to tempoarily drop the view on both
servers to test the situation.
If you have any update, please feel free to let's know. Thank you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================|||Hi John,
I've also experienced the drop in performance when going from SQL 2000 32
Bit to SQL 2005 64 Bit. After a lot of tuning I got it back to the same
performance as in SQL 2000, but this includes rewriting a lot of queries. It
seems that the query optimizer is working totally different than in SQL
2000. Complex derived tables and subqueries with inner subqueries are good
candidates for rewriting.
So much work to get the same speed.
Kay|||Peter - thanks for your most generous offer to take on looking over the
execution plans. For now, I will spare you of this. This weekend, I plan to
devote some serious time to optimizing and restructuring several queries. If
I do not succeed, I will then take you up on your offer. Thanks for being
such an excellent resource!
--
John
"Peter Yang [MSFT]" wrote:
> Hello John,
> By default, the optioins are checked and isually it is not recommended to
> uncheck "use row locks" and "use page locks" for the indexes. SQL Server
> shall select row locks/page locks for the better performance for specific
> queries. For example, for operations that only relates several rows, it is
> not efficient to only allow page locks. However, you may try to uncheck
> this to see if there is any difference.
> First, as Tibor mentioned, you may compare the exectution plans of both
> servers to make sure it is exact same. If it is same, you may try the
> following steps to get the exact
>
> DBCC TRACEON (8760, 8605, 8606, 8607)
> SET STATISTICS PROFILE ON
> SET STATISTICS TIME ON
> SET STATISTICS IO ON
> dbcc freeproccache
> dbcc dropcleanbuffers
> Go
> --Exec <place your stored procedure or query here>
> go
> SET STATISTICS PROFILE OFF
> SET STATISTICS TIME OFF
> SET STATISTICS IO OFF
> DBCC TRACEOFF (8760, 8605, 8606, 8607)
> go
>
> Please save the result execution plan in CSV file, and copy the io/cpu/time
> information in message window to a file, and send them to me at
> petery@.microsoft.com.
> In addtion, I'd like to know if the cluster server is a production server
> under heavy load. You may use perfmon to check if there is any memory/iO
> pressure on the server. Usually on a heavy load server, it is possible that
> a query might be slower than a server without other loads.
> http://www.extremeexperts.com/SQL/Articles/SQLCounters.aspx
> If query execution plan is different, it might be related to the following
> - The metadata of the tables used in the query (columns, indexes,
> constraints, indexed views, etc)
> - The size of the tables and other physical structures (number of rows,
> pages)
> - statistics (created at some point in time in the past over the data in
> the tables)
> - The MAXDOP setting
> - The amount of memory on the machine
> - Session settings (ANSI_NULLs, etc)
> - Difference in server engine
> You may want to check above to see if there is any difference. If the query
> is related to index view, you may want to tempoarily drop the view on both
> servers to test the situation.
> If you have any update, please feel free to let's know. Thank you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Partner Support
>
> =====================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
> ======================================================>
>|||Hello John,
I'm still interested in this issue. Did you try to solve the issue in the
weekend? If the issue persists, please get the informaiton I mentioend so
that we may further troubleshoot the issue. If you have other priorites,
please also let's know and we may work on the problem a little alter. Thank
you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================|||Hi Peter,
I have largely resolved the issue. The steps I took included
1. greatly expanding the resources of tempdb, giving it eight equally sized
200MB mdf/ndf files to work with on a RAID 1/0 LUN.
2. Using NOEXPAND to force the optimizer to choose indexed views. (This
made a HUGE difference - like 1000% performance gains.) You can see my post
on this in SQL Server.Programming under Indexed View Issue, dated 11/22/2006).
3. Identifying an error in the 2005 scripting wizard which has been sending
me on a tail-chase regarding indices on Indexed Views. You can see my post
on this at SQL Server.Server under WARNING-SCRIPTING ENGINE UNRELIABLE, dated
11/26/2006.
4. Reading Itzak Ben-Gan's two books and doing a lot of optimization work.
Bottom line, I had a particularly gruesome query that ran in 7 seconds with
SQL 2000, and then went up to 25 seconds in SQL 2005 x64. I got it down to
1.7 seconds now, still using SQL 2005 x64. This is just one of many examples.
Thanks for your help.
John
"Peter Yang [MSFT]" wrote:
> Hello John,
> I'm still interested in this issue. Did you try to solve the issue in the
> weekend? If the issue persists, please get the informaiton I mentioend so
> that we may further troubleshoot the issue. If you have other priorites,
> please also let's know and we may work on the problem a little alter. Thank
> you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Partner Support
>
> =====================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
> ======================================================>
>|||Hi John
Thanks for the feed back,
Links to the previous threads:
2. Indexed View Issue http://tinyurl.com/yj4qvn
3. WARNING-SCRIPTING ENGINE UNRELIABLE - http://tinyurl.com/wu6aq
IMO Itzik's books in the Inside SQL Server 2005 series are must buys for any
Programmer/DBA using SQL Server 2005.
John
"JT" wrote:
> Hi Peter,
> I have largely resolved the issue. The steps I took included
> 1. greatly expanding the resources of tempdb, giving it eight equally sized
> 200MB mdf/ndf files to work with on a RAID 1/0 LUN.
> 2. Using NOEXPAND to force the optimizer to choose indexed views. (This
> made a HUGE difference - like 1000% performance gains.) You can see my post
> on this in SQL Server.Programming under Indexed View Issue, dated 11/22/2006).
> 3. Identifying an error in the 2005 scripting wizard which has been sending
> me on a tail-chase regarding indices on Indexed Views. You can see my post
> on this at SQL Server.Server under WARNING-SCRIPTING ENGINE UNRELIABLE, dated
> 11/26/2006.
> 4. Reading Itzak Ben-Gan's two books and doing a lot of optimization work.
> Bottom line, I had a particularly gruesome query that ran in 7 seconds with
> SQL 2000, and then went up to 25 seconds in SQL 2005 x64. I got it down to
> 1.7 seconds now, still using SQL 2005 x64. This is just one of many examples.
> Thanks for your help.
>
> --
> John
>
> "Peter Yang [MSFT]" wrote:
> > Hello John,
> >
> > I'm still interested in this issue. Did you try to solve the issue in the
> > weekend? If the issue persists, please get the informaiton I mentioend so
> > that we may further troubleshoot the issue. If you have other priorites,
> > please also let's know and we may work on the problem a little alter. Thank
> > you.
> >
> > Best Regards,
> >
> > Peter Yang
> > MCSE2000/2003, MCSA, MCDBA
> > Microsoft Online Partner Support
> >
> >
> > =====================================================> >
> > This posting is provided "AS IS" with no warranties, and confers no rights.
> > ======================================================> >
> >
> >|||Hello John,
Thank you for sharing your experience on this issue and this shall
defenitely benefit the community. :-)
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
=====================================================This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

Wednesday, March 7, 2012

Problem with WHERE clause...

Hi All,
I keep getting the following error with my WHERE clause.
Msg 102, Level 15, State 1, Line 47
Incorrect syntax near '-'.
We've found that the code works if the segment " -
(CONVERT(Int,dbo.ReorderItemsTotals.OnPurchaseOrder))" is removed. So
it's clear that the error is within this segment.
The object "dbo.ReorderItemsTotals" is a view and uses a UNION command
in the SELECT statement. It joins two fields and outputs it as one
field - "OnPurchaseOrder". The two original fields are smallints and
the resulting UNION'd field is a varchar 10 - however I don't know why
this is.
Can anyone help fix this error? My code is as follows.
Many thanks in advance,
Rype
WHERE
(dbo.ProductAssembly.SubProduct IS NULL) AND
((((0.5 * dbo.SoldLast30TotalWith0Total.Despatched +
dbo.ReorderItemsTotals.SumOfSalesBackOrder) + (0.5 / 4 *
dbo.SoldLast120TotalWith0Total.Despatched) *
dbo.ReorderItemsTotals.ReorderLevel * 120) - (CONVERT(Int,
dbo.ReorderItemsTotals.Stock)) -
(CONVERT(Int,dbo.ReorderItemsTotals.OnPurchaseOrder)) +
dbo.ReorderItemsTotals.SumOfSalesBackOrder) > 0) OR
(dbo.ProductAssembly.SubProduct IS NULL) AND
(dbo.ProductDetails.Product1 < dbo.ReorderItemsTotalsSets.StockCode)
AND
(dbo.ProductDetails.Product1 + dbo.productdetails.product2 <
dbo.ReorderItemsTotalsSets.ReorderQuantity)This is a multi-part message in MIME format.
--=_NextPart_000_0007_01C804CC.9AEE5810
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Everything seems to check out using SSMS to balance the parentheses. I =do question if the logic is as you intend, given the groupings. Having =the OR out by itself like that is often not what is desired. Also, do =yourself a favor and start using aliases!! :-)
WHERE dbo.ProductAssembly.SubProduct IS NULL
AND ((((0.5 * dbo.SoldLast30TotalWith0Total.Despatched + =dbo.ReorderItemsTotals.SumOfSalesBackOrder) + (0.5 / 4 * dbo.SoldLast120TotalWith0Total.Despatched) * =dbo.ReorderItemsTotals.ReorderLevel * 120) - (CONVERT(Int, dbo.ReorderItemsTotals.Stock)) - =(CONVERT(Int,dbo.ReorderItemsTotals.OnPurchaseOrder)) +
dbo.ReorderItemsTotals.SumOfSalesBackOrder) > 0)
OR
(dbo.ProductAssembly.SubProduct IS NULL) AND (dbo.ProductDetails.Product1 < =dbo.ReorderItemsTotalsSets.StockCode)
AND (dbo.ProductDetails.Product1 + dbo.productdetails.product2 < =dbo.ReorderItemsTotalsSets.ReorderQuantity)
<ryanwpenfold@.gmail.com> wrote in message =news:1191330035.815038.230250@.n39g2000hsh.googlegroups.com...
> Hi All,
> > I keep getting the following error with my WHERE clause.
> > Msg 102, Level 15, State 1, Line 47
> Incorrect syntax near '-'.
> > We've found that the code works if the segment " -
> (CONVERT(Int,dbo.ReorderItemsTotals.OnPurchaseOrder))" is removed. So
> it's clear that the error is within this segment.
> > The object "dbo.ReorderItemsTotals" is a view and uses a UNION command
> in the SELECT statement. It joins two fields and outputs it as one
> field - "OnPurchaseOrder". The two original fields are smallints and
> the resulting UNION'd field is a varchar 10 - however I don't know why
> this is.
> > Can anyone help fix this error? My code is as follows.
> > Many thanks in advance,
> > Rype
> > > > WHERE
> (dbo.ProductAssembly.SubProduct IS NULL) AND
> ((((0.5 * dbo.SoldLast30TotalWith0Total.Despatched +
> dbo.ReorderItemsTotals.SumOfSalesBackOrder) + (0.5 / 4 *
> dbo.SoldLast120TotalWith0Total.Despatched) *
> dbo.ReorderItemsTotals.ReorderLevel * 120) - (CONVERT(Int,
> dbo.ReorderItemsTotals.Stock)) -
> (CONVERT(Int,dbo.ReorderItemsTotals.OnPurchaseOrder)) +
> dbo.ReorderItemsTotals.SumOfSalesBackOrder) > 0) OR
> (dbo.ProductAssembly.SubProduct IS NULL) AND
> (dbo.ProductDetails.Product1 < dbo.ReorderItemsTotalsSets.StockCode)
> AND
> (dbo.ProductDetails.Product1 + dbo.productdetails.product2 <
> dbo.ReorderItemsTotalsSets.ReorderQuantity)
>
--=_NextPart_000_0007_01C804CC.9AEE5810
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

Everything seems to check out using SSMS to balance the =parentheses. I do question if the logic is as you intend, given the groupings. =Having the OR out by itself like that is often not what is desired. Also, =do yourself a favor and start using aliases!! :-)
WHERE dbo.ProductAssembly.SubProduct IS NULL AND ((((0.5 * dbo.SoldLast30TotalWith0Total.Despatched + dbo.ReorderItemsTotals.SumOfSalesBackOrder) + (0.5 / 4 * dbo.SoldLast120TotalWith0Total.Despatched) * =dbo.ReorderItemsTotals.ReorderLevel * 120) - =(CONVERT(Int, dbo.ReorderItemsTotals.Stock)) - (CONVERT(Int,dbo.ReorderItemsTotals.OnPurchaseOrder)) + dbo.ReorderItemsTotals.SumOfSalesBackOrder) > =0) OR (dbo.ProductAssembly.SubProduct IS =NULL) AND (dbo.ProductDetails.Product1 < dbo.ReorderItemsTotalsSets.StockCode) AND =(dbo.ProductDetails.Product1 + dbo.productdetails.product2 < dbo.ReorderItemsTotalsSets.ReorderQuantity)
wrote in message news:=1191330035.815038.230250@.n39g2000hsh.googlegroups.com...> Hi All,> > I keep getting the following error with my =WHERE clause.> > Msg 102, Level 15, State 1, Line 47> =Incorrect syntax near '-'.> > We've found that the code works if the =segment " -> (CONVERT(Int,dbo.ReorderItemsTotals.OnPurchaseOrder))" is removed. So> it's clear that the error is within this segment.> > The object "dbo.ReorderItemsTotals" is a view =and uses a UNION command> in the SELECT statement. It joins two =fields and outputs it as one> field - "OnPurchaseOrder". The two =original fields are smallints and> the resulting UNION'd field is a =varchar 10 - however I don't know why> this is.> > Can anyone =help fix this error? My code is as follows.> > Many thanks in =advance,> > Rype> > > > =WHERE> (dbo.ProductAssembly.SubProduct IS NULL) AND> ((((0.5 * dbo.SoldLast30TotalWith0Total.Despatched +> dbo.ReorderItemsTotals.SumOfSalesBackOrder) + (0.5 / 4 *> dbo.SoldLast120TotalWith0Total.Despatched) *> dbo.ReorderItemsTotals.ReorderLevel * 120) - (CONVERT(Int,> dbo.ReorderItemsTotals.Stock)) -> (CONVERT(Int,dbo.ReorderItemsTotals.OnPurchaseOrder)) +> dbo.ReorderItemsTotals.SumOfSalesBackOrder) > 0) OR> (dbo.ProductAssembly.SubProduct IS NULL) AND> (dbo.ProductDetails.Product1 < =dbo.ReorderItemsTotalsSets.StockCode)> AND> (dbo.ProductDetails.Product1 + =dbo.productdetails.product2 <> =dbo.ReorderItemsTotalsSets.ReorderQuantity)>

--=_NextPart_000_0007_01C804CC.9AEE5810--

Saturday, February 25, 2012

Problem with viewing column permissions in Enterprise Manager

When trying to configure SQL Server security at the column level I ran into
a problem: if I assigned column-level security through Enterprise Manager it
seemed to work fine, but after reopening the permission dialog box the
permissions on some columns disappeared.
After doing some research I can now simulate the behaviour when running the
following script. In Enterprise manager the security on column 'Col3' does
not show after running the script, though it is there.
CREATE TABLE test
(
Col1 int NOT NULL,
Col2 nvarchar(50) NOT NULL,
Col3 int NOT NULL
)
GO
ALTER TABLE test
DROP COLUMN Col2
GO
GRANT SELECT ON test(Col3) TO public
GO
/* Correct: returns select permission on Col3 */
sp_helprotect 'test'
GO
/* Bug! Does not return anything. */
/* Problem is that sp_MSobjectprivs uses count(*) on syscolumns instead of
max(colid) to determine maximum column number */
sp_MSobjectprivs N'test','column',null,null,null,null,0,1
GO
Enterprise Manager seems to use the sp_MSobjectprivs procedure to retrieve
the column permissions, but that one fails if columns are not numbered
consecutively (as caused by the DROP COLUMN).
Stefan Cuypers.
Dear Stefan,
Thank you for your feedback. I have reproduced the problem. Please rest
assured that we do understand your concerns and that the known issue is
being worked in development with priority after we report it via our
internal channel. We strive to capture any and all product issues / product
feedback so as to ensure that we are continuously developing Microsoft
products to meet customer needs. This is exactly why feedback such as
yours is always taken very seriously.
While we also hope to see the issue fixed as soon as possible, we have
re-confirmed with the development team that there are no better workarounds
at this time. If there are any updates on the issue, I will do my best to
be the first one to let you know.
Once again, thank you for your time and feedback.
Sincerely,
Bill Cheng
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
| From: "Stefan Cuypers" <stefan.cuypers@.nospam.nospam>
| Subject: Problem with viewing column permissions in Enterprise Manager
| Date: Fri, 2 Jul 2004 16:15:01 +0200
| Lines: 35
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.3790.0
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.132
| Message-ID: <#kQW57DYEHA.2908@.TK2MSFTNGP10.phx.gbl>
| Newsgroups: microsoft.public.sqlserver.tools
| NNTP-Posting-Host: d576ae10.kabel.telenet.be 213.118.174.16
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP10.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.sqlserver.tools:24406
| X-Tomcat-NG: microsoft.public.sqlserver.tools
|
| When trying to configure SQL Server security at the column level I ran
into
| a problem: if I assigned column-level security through Enterprise Manager
it
| seemed to work fine, but after reopening the permission dialog box the
| permissions on some columns disappeared.
| After doing some research I can now simulate the behaviour when running
the
| following script. In Enterprise manager the security on column 'Col3' does
| not show after running the script, though it is there.
| CREATE TABLE test
| (
| Col1 int NOT NULL,
| Col2 nvarchar(50) NOT NULL,
| Col3 int NOT NULL
| )
| GO
| ALTER TABLE test
| DROP COLUMN Col2
| GO
| GRANT SELECT ON test(Col3) TO public
| GO
| /* Correct: returns select permission on Col3 */
| sp_helprotect 'test'
| GO
| /* Bug! Does not return anything. */
| /* Problem is that sp_MSobjectprivs uses count(*) on syscolumns instead of
| max(colid) to determine maximum column number */
| sp_MSobjectprivs N'test','column',null,null,null,null,0,1
| GO
|
| Enterprise Manager seems to use the sp_MSobjectprivs procedure to retrieve
| the column permissions, but that one fails if columns are not numbered
| consecutively (as caused by the DROP COLUMN).
|
| Stefan Cuypers.
|
|
|
|||Bill,
Thanks for the feedback. I'm glad you take it seriously and will try to fix
it in a next update.
Stefan.
""Bill Cheng"" <billchng@.online.microsoft.com> wrote in message
news:jNqMXDOYEHA.2352@.cpmsftngxa06.phx.gbl...
> Dear Stefan,
> Thank you for your feedback. I have reproduced the problem. Please rest
> assured that we do understand your concerns and that the known issue is
> being worked in development with priority after we report it via our
> internal channel. We strive to capture any and all product issues /
product
> feedback so as to ensure that we are continuously developing Microsoft
> products to meet customer needs. This is exactly why feedback such as
> yours is always taken very seriously.
> While we also hope to see the issue fixed as soon as possible, we have
> re-confirmed with the development team that there are no better
workarounds
> at this time. If there are any updates on the issue, I will do my best to
> be the first one to let you know.
> Once again, thank you for your time and feedback.
> Sincerely,
> Bill Cheng
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
> --
> | From: "Stefan Cuypers" <stefan.cuypers@.nospam.nospam>
> | Subject: Problem with viewing column permissions in Enterprise Manager
> | Date: Fri, 2 Jul 2004 16:15:01 +0200
> | Lines: 35
> | X-Priority: 3
> | X-MSMail-Priority: Normal
> | X-Newsreader: Microsoft Outlook Express 6.00.3790.0
> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.132
> | Message-ID: <#kQW57DYEHA.2908@.TK2MSFTNGP10.phx.gbl>
> | Newsgroups: microsoft.public.sqlserver.tools
> | NNTP-Posting-Host: d576ae10.kabel.telenet.be 213.118.174.16
> | Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP10.phx.gbl
> | Xref: cpmsftngxa06.phx.gbl microsoft.public.sqlserver.tools:24406
> | X-Tomcat-NG: microsoft.public.sqlserver.tools
> |
> | When trying to configure SQL Server security at the column level I ran
> into
> | a problem: if I assigned column-level security through Enterprise
Manager
> it
> | seemed to work fine, but after reopening the permission dialog box the
> | permissions on some columns disappeared.
> | After doing some research I can now simulate the behaviour when running
> the
> | following script. In Enterprise manager the security on column 'Col3'
does
> | not show after running the script, though it is there.
> | CREATE TABLE test
> | (
> | Col1 int NOT NULL,
> | Col2 nvarchar(50) NOT NULL,
> | Col3 int NOT NULL
> | )
> | GO
> | ALTER TABLE test
> | DROP COLUMN Col2
> | GO
> | GRANT SELECT ON test(Col3) TO public
> | GO
> | /* Correct: returns select permission on Col3 */
> | sp_helprotect 'test'
> | GO
> | /* Bug! Does not return anything. */
> | /* Problem is that sp_MSobjectprivs uses count(*) on syscolumns instead
of
> | max(colid) to determine maximum column number */
> | sp_MSobjectprivs N'test','column',null,null,null,null,0,1
> | GO
> |
> | Enterprise Manager seems to use the sp_MSobjectprivs procedure to
retrieve
> | the column permissions, but that one fails if columns are not numbered
> | consecutively (as caused by the DROP COLUMN).
> |
> | Stefan Cuypers.
> |
> |
> |
>