I have a SQL Report in SQL 2005 that has 2 datasets. The second
dataset queries a value that is passed as a parameter to the first
dataset. It works well as the main report but when I use it as a
linked report and put a default on parameter field and hide the
prompt, it gives me "xxx parameter is missing a value". It seems that
it's not reading the parameter at all.
Now if I have the second dataset as Non-queried and embed the value
and label fields on the report itself, it works well even as a linked
report. However, I dont want to do this because these values and
labels change. I cannot embed it on each report (around 50 of them)
and change each report one by one if there is a change.
I appreciate your help in advance.
Ben
%$^*&I finally got the report to work. The first dataset didn't recognize
the 3-character default value because it expected a 10 character
string (as declared in the second dataset). I just added seven
trailing spaces without quotes and it worked fine.
Ben
On Nov 15, 11:57 am, benito <lochinvar...@.gmail.com> wrote:
> I have a SQL Report in SQL 2005 that has 2 datasets. Theseconddatasetqueriesavaluethat is passed as a parameter to the firstdataset. It works well as the main report but when I use it as a
> linked report and put a default on parameter field and hide the
> prompt, it gives me "xxx parameter is missing avalue". It seems that
> it's not reading the parameter at all.
> Now if I have theseconddatasetas Non-queried and embed thevalue
> and label fields on the report itself, it works well even as a linked
> report. However, I dont want to do this because these values and
> labels change. I cannot embed it on each report (around 50 of them)
> and change each report one by one if there is a change.
> I appreciate your help in advance.
> Ben
> %$^*&
Showing posts with label second. Show all posts
Showing posts with label second. Show all posts
Monday, March 26, 2012
Parameter Does Not Work When Deployed
This is my first attempt at using a second dataset to fill a drop-down
parameter. This works fine inside of the designer but when I deploy to the
report server, there are no values in the drop down.
I thought perhaps it was because the data source name on the server is
different. In the past I would just update it on the server after I deploy
and it worked fine. After the deploy and after chaning the DS name, I edited
the server RDL and found that not all of the DS names had been updated. I
then edited the names in the RDL and uploaded manually thinking this was the
problem but the DD list still does not work.
Thanks for any help!Are you using a shared data source? This could be a credentials problem. I
always use a shared datasource. Personally, I don't see much of a reason to
ever not use a shared data source.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
news:OJhRIuNjFHA.3256@.TK2MSFTNGP12.phx.gbl...
> This is my first attempt at using a second dataset to fill a drop-down
> parameter. This works fine inside of the designer but when I deploy to the
> report server, there are no values in the drop down.
> I thought perhaps it was because the data source name on the server is
> different. In the past I would just update it on the server after I deploy
> and it worked fine. After the deploy and after chaning the DS name, I
> edited the server RDL and found that not all of the DS names had been
> updated. I then edited the names in the RDL and uploaded manually thinking
> this was the problem but the DD list still does not work.
> Thanks for any help!
>|||Bruce
Thanks for your reply
Yes, I have deployed other reports to the same folder, reset them to the
same data source and it always has worked fine. What is different is this is
the first time I used a second dataset in a report (to drive the lookup drop
down). It may not be the datasource, that was just a guess on my part. Are
there othe issues that could affect a query driven lookup such that it works
in the designer but not when deployed?
Thanks
Mike
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%23oQhumSjFHA.576@.TK2MSFTNGP15.phx.gbl...
> Are you using a shared data source? This could be a credentials problem. I
> always use a shared datasource. Personally, I don't see much of a reason
> to ever not use a shared data source.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
> news:OJhRIuNjFHA.3256@.TK2MSFTNGP12.phx.gbl...
>> This is my first attempt at using a second dataset to fill a drop-down
>> parameter. This works fine inside of the designer but when I deploy to
>> the report server, there are no values in the drop down.
>> I thought perhaps it was because the data source name on the server is
>> different. In the past I would just update it on the server after I
>> deploy and it worked fine. After the deploy and after chaning the DS
>> name, I edited the server RDL and found that not all of the DS names had
>> been updated. I then edited the names in the RDL and uploaded manually
>> thinking this was the problem but the DD list still does not work.
>> Thanks for any help!
>|||It could be a security issue on the database side of things. I've been
burned by that. I use one ID in development and then production is using
another one and the table/store procedure does not have the correct rights
for the production credentials. Take a look on the database at the table the
query is going against and see what the security access rights are set to.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
news:ulgIyGijFHA.3012@.TK2MSFTNGP12.phx.gbl...
> Bruce
> Thanks for your reply
> Yes, I have deployed other reports to the same folder, reset them to the
> same data source and it always has worked fine. What is different is this
> is the first time I used a second dataset in a report (to drive the lookup
> drop down). It may not be the datasource, that was just a guess on my
> part. Are there othe issues that could affect a query driven lookup such
> that it works in the designer but not when deployed?
> Thanks
> Mike
>
> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> news:%23oQhumSjFHA.576@.TK2MSFTNGP15.phx.gbl...
>> Are you using a shared data source? This could be a credentials problem.
>> I always use a shared datasource. Personally, I don't see much of a
>> reason to ever not use a shared data source.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
>> news:OJhRIuNjFHA.3256@.TK2MSFTNGP12.phx.gbl...
>> This is my first attempt at using a second dataset to fill a drop-down
>> parameter. This works fine inside of the designer but when I deploy to
>> the report server, there are no values in the drop down.
>> I thought perhaps it was because the data source name on the server is
>> different. In the past I would just update it on the server after I
>> deploy and it worked fine. After the deploy and after chaning the DS
>> name, I edited the server RDL and found that not all of the DS names had
>> been updated. I then edited the names in the RDL and uploaded manually
>> thinking this was the problem but the DD list still does not work.
>> Thanks for any help!
>>
>|||Bruce
The security seems ok and the main query for dataset-1 works fine. The same
data source is used for dataset-1 and dataset-2 which drives the param
drop-down list. Maybe it is not the data source since I am not getting any
erorrs. This is what happens: the the drop down list is horizontally
truncated and there are no values in displayed when you select it. It just
displays 'Select Value'.
Thanks
Mike
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%23fTmvMijFHA.3608@.TK2MSFTNGP12.phx.gbl...
> It could be a security issue on the database side of things. I've been
> burned by that. I use one ID in development and then production is using
> another one and the table/store procedure does not have the correct rights
> for the production credentials. Take a look on the database at the table
> the query is going against and see what the security access rights are set
> to.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
> news:ulgIyGijFHA.3012@.TK2MSFTNGP12.phx.gbl...
>> Bruce
>> Thanks for your reply
>> Yes, I have deployed other reports to the same folder, reset them to the
>> same data source and it always has worked fine. What is different is this
>> is the first time I used a second dataset in a report (to drive the
>> lookup drop down). It may not be the datasource, that was just a guess on
>> my part. Are there othe issues that could affect a query driven lookup
>> such that it works in the designer but not when deployed?
>> Thanks
>> Mike
>>
>> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
>> news:%23oQhumSjFHA.576@.TK2MSFTNGP15.phx.gbl...
>> Are you using a shared data source? This could be a credentials problem.
>> I always use a shared datasource. Personally, I don't see much of a
>> reason to ever not use a shared data source.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
>> news:OJhRIuNjFHA.3256@.TK2MSFTNGP12.phx.gbl...
>> This is my first attempt at using a second dataset to fill a drop-down
>> parameter. This works fine inside of the designer but when I deploy to
>> the report server, there are no values in the drop down.
>> I thought perhaps it was because the data source name on the server is
>> different. In the past I would just update it on the server after I
>> deploy and it worked fine. After the deploy and after chaning the DS
>> name, I edited the server RDL and found that not all of the DS names
>> had been updated. I then edited the names in the RDL and uploaded
>> manually thinking this was the problem but the DD list still does not
>> work.
>> Thanks for any help!
>>
>>
>
parameter. This works fine inside of the designer but when I deploy to the
report server, there are no values in the drop down.
I thought perhaps it was because the data source name on the server is
different. In the past I would just update it on the server after I deploy
and it worked fine. After the deploy and after chaning the DS name, I edited
the server RDL and found that not all of the DS names had been updated. I
then edited the names in the RDL and uploaded manually thinking this was the
problem but the DD list still does not work.
Thanks for any help!Are you using a shared data source? This could be a credentials problem. I
always use a shared datasource. Personally, I don't see much of a reason to
ever not use a shared data source.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
news:OJhRIuNjFHA.3256@.TK2MSFTNGP12.phx.gbl...
> This is my first attempt at using a second dataset to fill a drop-down
> parameter. This works fine inside of the designer but when I deploy to the
> report server, there are no values in the drop down.
> I thought perhaps it was because the data source name on the server is
> different. In the past I would just update it on the server after I deploy
> and it worked fine. After the deploy and after chaning the DS name, I
> edited the server RDL and found that not all of the DS names had been
> updated. I then edited the names in the RDL and uploaded manually thinking
> this was the problem but the DD list still does not work.
> Thanks for any help!
>|||Bruce
Thanks for your reply
Yes, I have deployed other reports to the same folder, reset them to the
same data source and it always has worked fine. What is different is this is
the first time I used a second dataset in a report (to drive the lookup drop
down). It may not be the datasource, that was just a guess on my part. Are
there othe issues that could affect a query driven lookup such that it works
in the designer but not when deployed?
Thanks
Mike
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%23oQhumSjFHA.576@.TK2MSFTNGP15.phx.gbl...
> Are you using a shared data source? This could be a credentials problem. I
> always use a shared datasource. Personally, I don't see much of a reason
> to ever not use a shared data source.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
> news:OJhRIuNjFHA.3256@.TK2MSFTNGP12.phx.gbl...
>> This is my first attempt at using a second dataset to fill a drop-down
>> parameter. This works fine inside of the designer but when I deploy to
>> the report server, there are no values in the drop down.
>> I thought perhaps it was because the data source name on the server is
>> different. In the past I would just update it on the server after I
>> deploy and it worked fine. After the deploy and after chaning the DS
>> name, I edited the server RDL and found that not all of the DS names had
>> been updated. I then edited the names in the RDL and uploaded manually
>> thinking this was the problem but the DD list still does not work.
>> Thanks for any help!
>|||It could be a security issue on the database side of things. I've been
burned by that. I use one ID in development and then production is using
another one and the table/store procedure does not have the correct rights
for the production credentials. Take a look on the database at the table the
query is going against and see what the security access rights are set to.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
news:ulgIyGijFHA.3012@.TK2MSFTNGP12.phx.gbl...
> Bruce
> Thanks for your reply
> Yes, I have deployed other reports to the same folder, reset them to the
> same data source and it always has worked fine. What is different is this
> is the first time I used a second dataset in a report (to drive the lookup
> drop down). It may not be the datasource, that was just a guess on my
> part. Are there othe issues that could affect a query driven lookup such
> that it works in the designer but not when deployed?
> Thanks
> Mike
>
> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> news:%23oQhumSjFHA.576@.TK2MSFTNGP15.phx.gbl...
>> Are you using a shared data source? This could be a credentials problem.
>> I always use a shared datasource. Personally, I don't see much of a
>> reason to ever not use a shared data source.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
>> news:OJhRIuNjFHA.3256@.TK2MSFTNGP12.phx.gbl...
>> This is my first attempt at using a second dataset to fill a drop-down
>> parameter. This works fine inside of the designer but when I deploy to
>> the report server, there are no values in the drop down.
>> I thought perhaps it was because the data source name on the server is
>> different. In the past I would just update it on the server after I
>> deploy and it worked fine. After the deploy and after chaning the DS
>> name, I edited the server RDL and found that not all of the DS names had
>> been updated. I then edited the names in the RDL and uploaded manually
>> thinking this was the problem but the DD list still does not work.
>> Thanks for any help!
>>
>|||Bruce
The security seems ok and the main query for dataset-1 works fine. The same
data source is used for dataset-1 and dataset-2 which drives the param
drop-down list. Maybe it is not the data source since I am not getting any
erorrs. This is what happens: the the drop down list is horizontally
truncated and there are no values in displayed when you select it. It just
displays 'Select Value'.
Thanks
Mike
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%23fTmvMijFHA.3608@.TK2MSFTNGP12.phx.gbl...
> It could be a security issue on the database side of things. I've been
> burned by that. I use one ID in development and then production is using
> another one and the table/store procedure does not have the correct rights
> for the production credentials. Take a look on the database at the table
> the query is going against and see what the security access rights are set
> to.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
> news:ulgIyGijFHA.3012@.TK2MSFTNGP12.phx.gbl...
>> Bruce
>> Thanks for your reply
>> Yes, I have deployed other reports to the same folder, reset them to the
>> same data source and it always has worked fine. What is different is this
>> is the first time I used a second dataset in a report (to drive the
>> lookup drop down). It may not be the datasource, that was just a guess on
>> my part. Are there othe issues that could affect a query driven lookup
>> such that it works in the designer but not when deployed?
>> Thanks
>> Mike
>>
>> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
>> news:%23oQhumSjFHA.576@.TK2MSFTNGP15.phx.gbl...
>> Are you using a shared data source? This could be a credentials problem.
>> I always use a shared datasource. Personally, I don't see much of a
>> reason to ever not use a shared data source.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Mike Harbinger" <MikeH@.Cybervillage.net> wrote in message
>> news:OJhRIuNjFHA.3256@.TK2MSFTNGP12.phx.gbl...
>> This is my first attempt at using a second dataset to fill a drop-down
>> parameter. This works fine inside of the designer but when I deploy to
>> the report server, there are no values in the drop down.
>> I thought perhaps it was because the data source name on the server is
>> different. In the past I would just update it on the server after I
>> deploy and it worked fine. After the deploy and after chaning the DS
>> name, I edited the server RDL and found that not all of the DS names
>> had been updated. I then edited the names in the RDL and uploaded
>> manually thinking this was the problem but the DD list still does not
>> work.
>> Thanks for any help!
>>
>>
>
Monday, March 12, 2012
Paging issue on conditionally set second table visibility
Hi. I am having a problem with a 2005 report that has two tables and is designed thru visual studio. The second table is set to page break before printing and also to repeater headers on new pages. It works fine just like that. However, if I place a condition on the visibilty of the table based on an input report parameter it does not page break before rendering the table. In fact it does not page break at all leaving me with an extremely long last page. The visiblity parameter does properly toggle. This is all occurring when rendering the report to the screen using the windows reportviewer. When I export to PDF it looks fine.
Any help would be great.
This is currently by design - when the visibility property is expression-based, the page break is ignored. We are considering changing this behavior in the next release.|||Thanks for the reply Fang.
I do hope you consider chaninging it. I can understand ignoring the page break when visibility is false but I am not sure why one would want to ignore it when visibility is true. Also, the way it is now the rendered report is not consistent between the screen and PDF.
|||Thanks so much for posting your problem. We are converting from crystal to reporting services and have been experiencing this same issue and were very puzzled. This "by design feature" is making a lot of our reports look very inconsistent with pagination between the viewer and printer or pdf. Reminds me of an early crystal reports viewer problem, which they fixed a long time ago...|||Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...|||
Spivey wrote:
Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...
what does next release meant , is it fixed in sp2 2005.
|||No, its not fixed, but I figured out a solution. The next release will coincide with the next release of SQL Server - 2008 sometime.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1771550&SiteID=1
|||What is wrong with the people at Microsoft? Just when you think they have done something right, they screw up something like this!
WHY WOULD ANYONE WANT TO IGNORE THE PAGE BREAK IF IT IS VISIBLE?!
Ugh!!!!!!!!!!!!!!!!!!!!!!!!!
Paging issue on conditionally set second table visibility
Hi. I am having a problem with a 2005 report that has two tables and is designed thru visual studio. The second table is set to page break before printing and also to repeater headers on new pages. It works fine just like that. However, if I place a condition on the visibilty of the table based on an input report parameter it does not page break before rendering the table. In fact it does not page break at all leaving me with an extremely long last page. The visiblity parameter does properly toggle. This is all occurring when rendering the report to the screen using the windows reportviewer. When I export to PDF it looks fine.
Any help would be great.
This is currently by design - when the visibility property is expression-based, the page break is ignored. We are considering changing this behavior in the next release.|||Thanks for the reply Fang.
I do hope you consider chaninging it. I can understand ignoring the page break when visibility is false but I am not sure why one would want to ignore it when visibility is true. Also, the way it is now the rendered report is not consistent between the screen and PDF.
|||Thanks so much for posting your problem. We are converting from crystal to reporting services and have been experiencing this same issue and were very puzzled. This "by design feature" is making a lot of our reports look very inconsistent with pagination between the viewer and printer or pdf. Reminds me of an early crystal reports viewer problem, which they fixed a long time ago...|||Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...|||
Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...
what does next release meant , is it fixed in sp2 2005.
|||No, its not fixed, but I figured out a solution. The next release will coincide with the next release of SQL Server - 2008 sometime.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1771550&SiteID=1
|||What is wrong with the people at Microsoft? Just when you think they have done something right, they screw up something like this!
WHY WOULD ANYONE WANT TO IGNORE THE PAGE BREAK IF IT IS VISIBLE?!
Ugh!!!!!!!!!!!!!!!!!!!!!!!!!
Paging issue on conditionally set second table visibility
Hi. I am having a problem with a 2005 report that has two tables and is designed thru visual studio. The second table is set to page break before printing and also to repeater headers on new pages. It works fine just like that. However, if I place a condition on the visibilty of the table based on an input report parameter it does not page break before rendering the table. In fact it does not page break at all leaving me with an extremely long last page. The visiblity parameter does properly toggle. This is all occurring when rendering the report to the screen using the windows reportviewer. When I export to PDF it looks fine.
Any help would be great.
This is currently by design - when the visibility property is expression-based, the page break is ignored. We are considering changing this behavior in the next release.|||Thanks for the reply Fang.
I do hope you consider chaninging it. I can understand ignoring the page break when visibility is false but I am not sure why one would want to ignore it when visibility is true. Also, the way it is now the rendered report is not consistent between the screen and PDF.
|||Thanks so much for posting your problem. We are converting from crystal to reporting services and have been experiencing this same issue and were very puzzled. This "by design feature" is making a lot of our reports look very inconsistent with pagination between the viewer and printer or pdf. Reminds me of an early crystal reports viewer problem, which they fixed a long time ago...|||Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...|||Spivey wrote:
Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...
what does next release meant , is it fixed in sp2 2005.
|||No, its not fixed, but I figured out a solution. The next release will coincide with the next release of SQL Server - 2008 sometime.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1771550&SiteID=1
|||What is wrong with the people at Microsoft? Just when you think they have done something right, they screw up something like this!
WHY WOULD ANYONE WANT TO IGNORE THE PAGE BREAK IF IT IS VISIBLE?!
Ugh!!!!!!!!!!!!!!!!!!!!!!!!!
Paging issue on conditionally set second table visibility
Hi. I am having a problem with a 2005 report that has two tables and is designed thru visual studio. The second table is set to page break before printing and also to repeater headers on new pages. It works fine just like that. However, if I place a condition on the visibilty of the table based on an input report parameter it does not page break before rendering the table. In fact it does not page break at all leaving me with an extremely long last page. The visiblity parameter does properly toggle. This is all occurring when rendering the report to the screen using the windows reportviewer. When I export to PDF it looks fine.
Any help would be great.
This is currently by design - when the visibility property is expression-based, the page break is ignored. We are considering changing this behavior in the next release.|||Thanks for the reply Fang.
I do hope you consider chaninging it. I can understand ignoring the page break when visibility is false but I am not sure why one would want to ignore it when visibility is true. Also, the way it is now the rendered report is not consistent between the screen and PDF.
|||Thanks so much for posting your problem. We are converting from crystal to reporting services and have been experiencing this same issue and were very puzzled. This "by design feature" is making a lot of our reports look very inconsistent with pagination between the viewer and printer or pdf. Reminds me of an early crystal reports viewer problem, which they fixed a long time ago...|||Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...|||
Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...
what does next release meant , is it fixed in sp2 2005.
|||No, its not fixed, but I figured out a solution. The next release will coincide with the next release of SQL Server - 2008 sometime.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1771550&SiteID=1
|||What is wrong with the people at Microsoft? Just when you think they have done something right, they screw up something like this!
WHY WOULD ANYONE WANT TO IGNORE THE PAGE BREAK IF IT IS VISIBLE?!
Ugh!!!!!!!!!!!!!!!!!!!!!!!!!
Friday, March 9, 2012
Paging
What does it mean when your cpu is low (20%ish), you avg
disk queue length is reasonable and your pages/second is
through the roof for about 15 minutes? (50-2000 pages/sec)
Not enough RAM I assume? Or could there be something else
causing it?Could be that data is being read from disk that wasn't in memory, although
you need a lot of data to keep that up for 15 minutes. More likely that
there is an operation going on that doesn't fit in memory completely and SQL
Server is using tempdb to store intermediate results. ORDER BY or DISTINCT
on a large dataset is a common cause for this.
You can use SQL Profiler and trace Error and Warnings:Hash Warning. If you
get these it's a sign of the above mentioned problem.
--
Jacco Schalkwijk
SQL Server MVP
"Baffled" <anonymous@.discussions.microsoft.com> wrote in message
news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
> What does it mean when your cpu is low (20%ish), you avg
> disk queue length is reasonable and your pages/second is
> through the roof for about 15 minutes? (50-2000 pages/sec)
> Not enough RAM I assume? Or could there be something else
> causing it?|||I just did some research and found three things were going
on during that time period (Sql Server 2000 btw):
1. A checkdb of a good sized database (about 95G).
2. Snapshot replication to two servers.
3. Backups of the same database that was 95g above.
I'm pretty sure #3 is low level - we took compression
out. Can #1 or #2 swallow up a lot of RAM?
Btw, it was at the very end of the checkdb that the paging
occurred, i.e. the last 15-20 minutes of a 2+ hour job.
Do you know if checkdb is particulary ram/cpu intensive at
the very end for some reason?
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
>> What does it mean when your cpu is low (20%ish), you avg
>> disk queue length is reasonable and your pages/second is
>> through the roof for about 15 minutes? (50-2000
pages/sec)
>> Not enough RAM I assume? Or could there be something
else
>> causing it?
>
>.
>|||I just did some research and found three things were going
on during that time period (Sql Server 2000 btw):
1. A checkdb of a good sized database (about 95G).
2. Snapshot replication to two servers.
3. Backups of the same database that was 95g above.
I'm pretty sure #3 is low level - we took compression
out. Can #1 or #2 swallow up a lot of RAM?
Btw, it was at the very end of the checkdb that the paging
occurred, i.e. the last 15-20 minutes of a 2+ hour job.
Do you know if checkdb is particulary ram/cpu intensive at
the very end for some reason?
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
>> What does it mean when your cpu is low (20%ish), you avg
>> disk queue length is reasonable and your pages/second is
>> through the roof for about 15 minutes? (50-2000
pages/sec)
>> Not enough RAM I assume? Or could there be something
else
>> causing it?
>
>.
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
>> What does it mean when your cpu is low (20%ish), you avg
>> disk queue length is reasonable and your pages/second is
>> through the roof for about 15 minutes? (50-2000
pages/sec)
>> Not enough RAM I assume? Or could there be something
else
>> causing it?
>
>.
>|||I don't think there is anything in particular going on towards the end of
DBCC CHECKDB. You might get a lot of activity with DBCC CHECKDB if you have
an error, for example a corrupt index. But that can happen at any time
during DBCC CHECKDB, not specifically at the end.
In the scenario you describe there is of course a lot of activity going on
at the same time. Can you give some more information about your disk set up?
Is everything on the same disk/array or on multiple disks?
--
Jacco Schalkwijk
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:268f01c4ad66$8102cb90$a401280a@.phx.gbl...
>I just did some research and found three things were going
> on during that time period (Sql Server 2000 btw):
> 1. A checkdb of a good sized database (about 95G).
> 2. Snapshot replication to two servers.
> 3. Backups of the same database that was 95g above.
> I'm pretty sure #3 is low level - we took compression
> out. Can #1 or #2 swallow up a lot of RAM?
> Btw, it was at the very end of the checkdb that the paging
> occurred, i.e. the last 15-20 minutes of a 2+ hour job.
> Do you know if checkdb is particulary ram/cpu intensive at
> the very end for some reason?
>
>>--Original Message--
>>Could be that data is being read from disk that wasn't in
> memory, although
>>you need a lot of data to keep that up for 15 minutes.
> More likely that
>>there is an operation going on that doesn't fit in memory
> completely and SQL
>>Server is using tempdb to store intermediate results.
> ORDER BY or DISTINCT
>>on a large dataset is a common cause for this.
>>You can use SQL Profiler and trace Error and
> Warnings:Hash Warning. If you
>>get these it's a sign of the above mentioned problem.
>>--
>>Jacco Schalkwijk
>>SQL Server MVP
>>
>>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
> message
>>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
>> What does it mean when your cpu is low (20%ish), you avg
>> disk queue length is reasonable and your pages/second is
>> through the roof for about 15 minutes? (50-2000
> pages/sec)
>> Not enough RAM I assume? Or could there be something
> else
>> causing it?
>>
>>.
disk queue length is reasonable and your pages/second is
through the roof for about 15 minutes? (50-2000 pages/sec)
Not enough RAM I assume? Or could there be something else
causing it?Could be that data is being read from disk that wasn't in memory, although
you need a lot of data to keep that up for 15 minutes. More likely that
there is an operation going on that doesn't fit in memory completely and SQL
Server is using tempdb to store intermediate results. ORDER BY or DISTINCT
on a large dataset is a common cause for this.
You can use SQL Profiler and trace Error and Warnings:Hash Warning. If you
get these it's a sign of the above mentioned problem.
--
Jacco Schalkwijk
SQL Server MVP
"Baffled" <anonymous@.discussions.microsoft.com> wrote in message
news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
> What does it mean when your cpu is low (20%ish), you avg
> disk queue length is reasonable and your pages/second is
> through the roof for about 15 minutes? (50-2000 pages/sec)
> Not enough RAM I assume? Or could there be something else
> causing it?|||I just did some research and found three things were going
on during that time period (Sql Server 2000 btw):
1. A checkdb of a good sized database (about 95G).
2. Snapshot replication to two servers.
3. Backups of the same database that was 95g above.
I'm pretty sure #3 is low level - we took compression
out. Can #1 or #2 swallow up a lot of RAM?
Btw, it was at the very end of the checkdb that the paging
occurred, i.e. the last 15-20 minutes of a 2+ hour job.
Do you know if checkdb is particulary ram/cpu intensive at
the very end for some reason?
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
>> What does it mean when your cpu is low (20%ish), you avg
>> disk queue length is reasonable and your pages/second is
>> through the roof for about 15 minutes? (50-2000
pages/sec)
>> Not enough RAM I assume? Or could there be something
else
>> causing it?
>
>.
>|||I just did some research and found three things were going
on during that time period (Sql Server 2000 btw):
1. A checkdb of a good sized database (about 95G).
2. Snapshot replication to two servers.
3. Backups of the same database that was 95g above.
I'm pretty sure #3 is low level - we took compression
out. Can #1 or #2 swallow up a lot of RAM?
Btw, it was at the very end of the checkdb that the paging
occurred, i.e. the last 15-20 minutes of a 2+ hour job.
Do you know if checkdb is particulary ram/cpu intensive at
the very end for some reason?
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
>> What does it mean when your cpu is low (20%ish), you avg
>> disk queue length is reasonable and your pages/second is
>> through the roof for about 15 minutes? (50-2000
pages/sec)
>> Not enough RAM I assume? Or could there be something
else
>> causing it?
>
>.
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
>> What does it mean when your cpu is low (20%ish), you avg
>> disk queue length is reasonable and your pages/second is
>> through the roof for about 15 minutes? (50-2000
pages/sec)
>> Not enough RAM I assume? Or could there be something
else
>> causing it?
>
>.
>|||I don't think there is anything in particular going on towards the end of
DBCC CHECKDB. You might get a lot of activity with DBCC CHECKDB if you have
an error, for example a corrupt index. But that can happen at any time
during DBCC CHECKDB, not specifically at the end.
In the scenario you describe there is of course a lot of activity going on
at the same time. Can you give some more information about your disk set up?
Is everything on the same disk/array or on multiple disks?
--
Jacco Schalkwijk
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:268f01c4ad66$8102cb90$a401280a@.phx.gbl...
>I just did some research and found three things were going
> on during that time period (Sql Server 2000 btw):
> 1. A checkdb of a good sized database (about 95G).
> 2. Snapshot replication to two servers.
> 3. Backups of the same database that was 95g above.
> I'm pretty sure #3 is low level - we took compression
> out. Can #1 or #2 swallow up a lot of RAM?
> Btw, it was at the very end of the checkdb that the paging
> occurred, i.e. the last 15-20 minutes of a 2+ hour job.
> Do you know if checkdb is particulary ram/cpu intensive at
> the very end for some reason?
>
>>--Original Message--
>>Could be that data is being read from disk that wasn't in
> memory, although
>>you need a lot of data to keep that up for 15 minutes.
> More likely that
>>there is an operation going on that doesn't fit in memory
> completely and SQL
>>Server is using tempdb to store intermediate results.
> ORDER BY or DISTINCT
>>on a large dataset is a common cause for this.
>>You can use SQL Profiler and trace Error and
> Warnings:Hash Warning. If you
>>get these it's a sign of the above mentioned problem.
>>--
>>Jacco Schalkwijk
>>SQL Server MVP
>>
>>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
> message
>>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
>> What does it mean when your cpu is low (20%ish), you avg
>> disk queue length is reasonable and your pages/second is
>> through the roof for about 15 minutes? (50-2000
> pages/sec)
>> Not enough RAM I assume? Or could there be something
> else
>> causing it?
>>
>>.
Paging
What does it mean when your cpu is low (20%ish), you avg
disk queue length is reasonable and your pages/second is
through the roof for about 15 minutes? (50-2000 pages/sec)
Not enough RAM I assume? Or could there be something else
causing it?
Could be that data is being read from disk that wasn't in memory, although
you need a lot of data to keep that up for 15 minutes. More likely that
there is an operation going on that doesn't fit in memory completely and SQL
Server is using tempdb to store intermediate results. ORDER BY or DISTINCT
on a large dataset is a common cause for this.
You can use SQL Profiler and trace Error and Warnings:Hash Warning. If you
get these it's a sign of the above mentioned problem.
Jacco Schalkwijk
SQL Server MVP
"Baffled" <anonymous@.discussions.microsoft.com> wrote in message
news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
> What does it mean when your cpu is low (20%ish), you avg
> disk queue length is reasonable and your pages/second is
> through the roof for about 15 minutes? (50-2000 pages/sec)
> Not enough RAM I assume? Or could there be something else
> causing it?
|||I just did some research and found three things were going
on during that time period (Sql Server 2000 btw):
1. A checkdb of a good sized database (about 95G).
2. Snapshot replication to two servers.
3. Backups of the same database that was 95g above.
I'm pretty sure #3 is low level - we took compression
out. Can #1 or #2 swallow up a lot of RAM?
Btw, it was at the very end of the checkdb that the paging
occurred, i.e. the last 15-20 minutes of a 2+ hour job.
Do you know if checkdb is particulary ram/cpu intensive at
the very end for some reason?
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
pages/sec)[vbcol=seagreen]
else
>
>.
>
|||I just did some research and found three things were going
on during that time period (Sql Server 2000 btw):
1. A checkdb of a good sized database (about 95G).
2. Snapshot replication to two servers.
3. Backups of the same database that was 95g above.
I'm pretty sure #3 is low level - we took compression
out. Can #1 or #2 swallow up a lot of RAM?
Btw, it was at the very end of the checkdb that the paging
occurred, i.e. the last 15-20 minutes of a 2+ hour job.
Do you know if checkdb is particulary ram/cpu intensive at
the very end for some reason?
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
pages/sec)[vbcol=seagreen]
else
>
>.
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
pages/sec)[vbcol=seagreen]
else
>
>.
>
|||I don't think there is anything in particular going on towards the end of
DBCC CHECKDB. You might get a lot of activity with DBCC CHECKDB if you have
an error, for example a corrupt index. But that can happen at any time
during DBCC CHECKDB, not specifically at the end.
In the scenario you describe there is of course a lot of activity going on
at the same time. Can you give some more information about your disk set up?
Is everything on the same disk/array or on multiple disks?
Jacco Schalkwijk
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:268f01c4ad66$8102cb90$a401280a@.phx.gbl...[vbcol=seagreen]
>I just did some research and found three things were going
> on during that time period (Sql Server 2000 btw):
> 1. A checkdb of a good sized database (about 95G).
> 2. Snapshot replication to two servers.
> 3. Backups of the same database that was 95g above.
> I'm pretty sure #3 is low level - we took compression
> out. Can #1 or #2 swallow up a lot of RAM?
> Btw, it was at the very end of the checkdb that the paging
> occurred, i.e. the last 15-20 minutes of a 2+ hour job.
> Do you know if checkdb is particulary ram/cpu intensive at
> the very end for some reason?
>
> memory, although
> More likely that
> completely and SQL
> ORDER BY or DISTINCT
> Warnings:Hash Warning. If you
> message
> pages/sec)
> else
disk queue length is reasonable and your pages/second is
through the roof for about 15 minutes? (50-2000 pages/sec)
Not enough RAM I assume? Or could there be something else
causing it?
Could be that data is being read from disk that wasn't in memory, although
you need a lot of data to keep that up for 15 minutes. More likely that
there is an operation going on that doesn't fit in memory completely and SQL
Server is using tempdb to store intermediate results. ORDER BY or DISTINCT
on a large dataset is a common cause for this.
You can use SQL Profiler and trace Error and Warnings:Hash Warning. If you
get these it's a sign of the above mentioned problem.
Jacco Schalkwijk
SQL Server MVP
"Baffled" <anonymous@.discussions.microsoft.com> wrote in message
news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
> What does it mean when your cpu is low (20%ish), you avg
> disk queue length is reasonable and your pages/second is
> through the roof for about 15 minutes? (50-2000 pages/sec)
> Not enough RAM I assume? Or could there be something else
> causing it?
|||I just did some research and found three things were going
on during that time period (Sql Server 2000 btw):
1. A checkdb of a good sized database (about 95G).
2. Snapshot replication to two servers.
3. Backups of the same database that was 95g above.
I'm pretty sure #3 is low level - we took compression
out. Can #1 or #2 swallow up a lot of RAM?
Btw, it was at the very end of the checkdb that the paging
occurred, i.e. the last 15-20 minutes of a 2+ hour job.
Do you know if checkdb is particulary ram/cpu intensive at
the very end for some reason?
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
pages/sec)[vbcol=seagreen]
else
>
>.
>
|||I just did some research and found three things were going
on during that time period (Sql Server 2000 btw):
1. A checkdb of a good sized database (about 95G).
2. Snapshot replication to two servers.
3. Backups of the same database that was 95g above.
I'm pretty sure #3 is low level - we took compression
out. Can #1 or #2 swallow up a lot of RAM?
Btw, it was at the very end of the checkdb that the paging
occurred, i.e. the last 15-20 minutes of a 2+ hour job.
Do you know if checkdb is particulary ram/cpu intensive at
the very end for some reason?
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
pages/sec)[vbcol=seagreen]
else
>
>.
>--Original Message--
>Could be that data is being read from disk that wasn't in
memory, although
>you need a lot of data to keep that up for 15 minutes.
More likely that
>there is an operation going on that doesn't fit in memory
completely and SQL
>Server is using tempdb to store intermediate results.
ORDER BY or DISTINCT
>on a large dataset is a common cause for this.
>You can use SQL Profiler and trace Error and
Warnings:Hash Warning. If you
>get these it's a sign of the above mentioned problem.
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Baffled" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:0a6301c4ad5f$191bd7d0$a501280a@.phx.gbl...
pages/sec)[vbcol=seagreen]
else
>
>.
>
|||I don't think there is anything in particular going on towards the end of
DBCC CHECKDB. You might get a lot of activity with DBCC CHECKDB if you have
an error, for example a corrupt index. But that can happen at any time
during DBCC CHECKDB, not specifically at the end.
In the scenario you describe there is of course a lot of activity going on
at the same time. Can you give some more information about your disk set up?
Is everything on the same disk/array or on multiple disks?
Jacco Schalkwijk
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:268f01c4ad66$8102cb90$a401280a@.phx.gbl...[vbcol=seagreen]
>I just did some research and found three things were going
> on during that time period (Sql Server 2000 btw):
> 1. A checkdb of a good sized database (about 95G).
> 2. Snapshot replication to two servers.
> 3. Backups of the same database that was 95g above.
> I'm pretty sure #3 is low level - we took compression
> out. Can #1 or #2 swallow up a lot of RAM?
> Btw, it was at the very end of the checkdb that the paging
> occurred, i.e. the last 15-20 minutes of a 2+ hour job.
> Do you know if checkdb is particulary ram/cpu intensive at
> the very end for some reason?
>
> memory, although
> More likely that
> completely and SQL
> ORDER BY or DISTINCT
> Warnings:Hash Warning. If you
> message
> pages/sec)
> else
Subscribe to:
Posts (Atom)