Flat File with random bad rows.

I have a text file that come from our client that is Column deliminated by ~ and row deliminated by {CR}{LF}.

There is a comment field that appearently is not cleaned up and has {CR}{LF} within the comment field.

I am new to SSIS and I'm wondering if there is a way to detect and correct the bad rows?

example file formet:

ORDERID~DATE~Comment~Address

1~2/3/2007~Some Comment~1234 oak st

2~2/3/2007~Some messed

up comment~345 oak st.

3~2/3/2007~Another comment~3214 asdf blvd.

Thank you.

You can use the Microsoft Visual Basic .NET RTrim function in a script run from the Script Component (configured as a transformation), to remove white space characters such as line feed and carriage return characters.

So the package data flow would include a Flat File Source connected to a Script Component. The output of the Script Component can then be sent to a destination or another transformation.

For information about the VB function, see "LTrim; RTrim; and Trim functions" at http://msdn2.microsoft.com/en-us/library/h9wz3dez(VS.71).aspx. For information about the Script Component, see "Extending the Data Flow with the Script Component" at http://msdn2.microsoft.com/en-us/library/ms136118.aspx.

|||If you do not want to mess with scripting you could use the REPLACE function in a Derived Column task and replace the space with another character.|||

How do you specify the line-feed character in the REPLACE function?

|||

Try

Code Snippet

\n

Generally, you use a \ character to escape special characters. \n indicates new line, \t indicates tab, etc.

|||

Thanks John, that works great

|||

If you enclose the escape character in quotes ("\n"), the expression will parse. For more information about using characters that require escape sequences in string literals, see "Literals (SSIS)" at http://msdn2.microsoft.com/en-us/library/ms141001.aspx.

Flat File with random bad rows.

I have a text file that come from our client that is Column deliminated by ~ and row deliminated by {CR}{LF}.

There is a comment field that appearently is not cleaned up and has {CR}{LF} within the comment field.

I am new to SSIS and I'm wondering if there is a way to detect and correct the bad rows?

example file formet:

ORDERID~DATE~Comment~Address

1~2/3/2007~Some Comment~1234 oak st

2~2/3/2007~Some messed

up comment~345 oak st.

3~2/3/2007~Another comment~3214 asdf blvd.

Thank you.

You can use the Microsoft Visual Basic .NET RTrim function in a script run from the Script Component (configured as a transformation), to remove white space characters such as line feed and carriage return characters.

So the package data flow would include a Flat File Source connected to a Script Component. The output of the Script Component can then be sent to a destination or another transformation.

For information about the VB function, see "LTrim; RTrim; and Trim functions" at http://msdn2.microsoft.com/en-us/library/h9wz3dez(VS.71).aspx. For information about the Script Component, see "Extending the Data Flow with the Script Component" at http://msdn2.microsoft.com/en-us/library/ms136118.aspx.

|||If you do not want to mess with scripting you could use the REPLACE function in a Derived Column task and replace the space with another character.

|||

How do you specify the line-feed character in the REPLACE function?

|||

Try

Code Snippet

\n

Generally, you use a \ character to escape special characters. \n indicates new line, \t indicates tab, etc.

|||

Thanks John, that works great

|||

If you enclose the escape character in quotes ("\n"), the expression will parse. For more information about using characters that require escape sequences in string literals, see "Literals (SSIS)" at http://msdn2.microsoft.com/en-us/library/ms141001.aspx.

Flat File with random bad rows.

I have a text file that come from our client that is Column deliminated by ~ and row deliminated by {CR}{LF}.

There is a comment field that appearently is not cleaned up and has {CR}{LF} within the comment field.

I am new to SSIS and I'm wondering if there is a way to detect and correct the bad rows?

example file formet:

ORDERID~DATE~Comment~Address

1~2/3/2007~Some Comment~1234 oak st

2~2/3/2007~Some messed

up comment~345 oak st.

3~2/3/2007~Another comment~3214 asdf blvd.

Thank you.

You can use the Microsoft Visual Basic .NET RTrim function in a script run from the Script Component (configured as a transformation), to remove white space characters such as line feed and carriage return characters.

So the package data flow would include a Flat File Source connected to a Script Component. The output of the Script Component can then be sent to a destination or another transformation.

For information about the VB function, see "LTrim; RTrim; and Trim functions" at http://msdn2.microsoft.com/en-us/library/h9wz3dez(VS.71).aspx. For information about the Script Component, see "Extending the Data Flow with the Script Component" at http://msdn2.microsoft.com/en-us/library/ms136118.aspx.

|||If you do not want to mess with scripting you could use the REPLACE function in a Derived Column task and replace the space with another character.|||

How do you specify the line-feed character in the REPLACE function?

|||

Try

Code Snippet

\n

Generally, you use a \ character to escape special characters. \n indicates new line, \t indicates tab, etc.

|||

Thanks John, that works great

|||

If you enclose the escape character in quotes ("\n"), the expression will parse. For more information about using characters that require escape sequences in string literals, see "Literals (SSIS)" at http://msdn2.microsoft.com/en-us/library/ms141001.aspx.

First Time Delay on client systems

Sorry to repost this, but need to in order to hopefully get a response from
Microsoft:
I've just set up a SQL Reporting Services server.
All seems to be working fine, however I've noticed that when a report is
opened from a user system accessing the report server for the first time, the
report takes a very long time to open (a few minutes in some cases), and
sometimes I have to abort it and start again.
This is a report that should take a couple of seconds at most. Once the
report does finally open, it opens fine from then on, even when refreshed, or
run by different parameters. Also all other reports availale to the user also
run fine after that first one finally opens.
There are no errors, just the Report is being generated message. It's like
the server has to get aquainted with the machine accessing it the first
time...
Again, once the report has run, this problem goes away. I have tested this
on around 10 different user systems, with the same results on all of them,
some are Win2k, some are XP. The report server is running on a dual
processor, clean install Server 2003, SQL Server 2000 sp 3a.
So far it appears to be machine, rather than user account, related...
Any assistance would be greatly appreciated. I'm holding off a full on roll
out of this until I get this solved, as it will certainly drive users crazy.
Thanks,
TomTHi Tomt,
Thanks for your posting!
From your descriptions, I understood that you would like to know why there
will be a delay (a few minutes in some cases) when you first time access
Reports. Have I understood you? Correct me if I was wrong.
Based on my konwledge, this is Reporting Services by design behavior. The
first user who runs the report with a unique region code creates a cached
report that contains data for that region. Subsequent users who request a
report using the same region code get the cached copy. create that report
will cost a lot of time.
The report server caches reports based on report execution options.
Execution options determine whether a report is cached and the length of
time it stays in cache. After some number of minutes or at a scheduled
time, the cache is emptied. The cache stays empty until a new report
execution operation occurs and a new copy of the report is cached.
Thank you for your patience and corporation. If you have any questions or
concerns, don't hesitate to let me know. We are always here to be of
assistance!
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Michael,
I'm not sure what you mean by region code...
What I'm seeing is for example: I open a report on my system, which has
previously accessed the report server and experience no delay. I go to
another system, which has never accessed that server, and run the same
report, and get a delay of up to a few minutes.
Hope that is clear...
Thanks for your help,
Tom
"Michael Cheng [MSFT]" wrote:
> Hi Tomt,
> Thanks for your posting!
> From your descriptions, I understood that you would like to know why there
> will be a delay (a few minutes in some cases) when you first time access
> Reports. Have I understood you? Correct me if I was wrong.
> Based on my konwledge, this is Reporting Services by design behavior. The
> first user who runs the report with a unique region code creates a cached
> report that contains data for that region. Subsequent users who request a
> report using the same region code get the cached copy. create that report
> will cost a lot of time.
> The report server caches reports based on report execution options.
> Execution options determine whether a report is cached and the length of
> time it stays in cache. After some number of minutes or at a scheduled
> time, the cache is emptied. The cache stays empty until a new report
> execution operation occurs and a new copy of the report is cached.
> Thank you for your patience and corporation. If you have any questions or
> concerns, don't hesitate to let me know. We are always here to be of
> assistance!
>
> Sincerely yours,
> Michael Cheng
> Microsoft Online Partner Support
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> =====================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||I'm sure he meant report query parameters and region code was the specific
one in his head for an example.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"TomT" <tomt@.newsgroup.nospam> wrote in message
news:FC1995F8-D81D-4049-87EC-4B88A4DDB8BB@.microsoft.com...
> Michael,
> I'm not sure what you mean by region code...
> What I'm seeing is for example: I open a report on my system, which has
> previously accessed the report server and experience no delay. I go to
> another system, which has never accessed that server, and run the same
> report, and get a delay of up to a few minutes.
> Hope that is clear...
> Thanks for your help,
> Tom
> "Michael Cheng [MSFT]" wrote:
>> Hi Tomt,
>> Thanks for your posting!
>> From your descriptions, I understood that you would like to know why
>> there
>> will be a delay (a few minutes in some cases) when you first time access
>> Reports. Have I understood you? Correct me if I was wrong.
>> Based on my konwledge, this is Reporting Services by design behavior. The
>> first user who runs the report with a unique region code creates a cached
>> report that contains data for that region. Subsequent users who request a
>> report using the same region code get the cached copy. create that report
>> will cost a lot of time.
>> The report server caches reports based on report execution options.
>> Execution options determine whether a report is cached and the length of
>> time it stays in cache. After some number of minutes or at a scheduled
>> time, the cache is emptied. The cache stays empty until a new report
>> execution operation occurs and a new copy of the report is cached.
>> Thank you for your patience and corporation. If you have any questions or
>> concerns, don't hesitate to let me know. We are always here to be of
>> assistance!
>>
>> Sincerely yours,
>> Michael Cheng
>> Microsoft Online Partner Support
>> When responding to posts, please "Reply to Group" via your newsreader so
>> that others may learn and benefit from your issue.
>> =====================================================>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>|||Ok, thanks. If that is the case, that is not the situation I'm talking about,
it seems to be related to whether or not a system has ever accessed the
server at all, there are no delays on systems that have, regardless of
parameters.
Thanks
"Jeff A. Stucker" wrote:
> I'm sure he meant report query parameters and region code was the specific
> one in his head for an example.
> --
> Cheers,
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---
> "TomT" <tomt@.newsgroup.nospam> wrote in message
> news:FC1995F8-D81D-4049-87EC-4B88A4DDB8BB@.microsoft.com...
> > Michael,
> >
> > I'm not sure what you mean by region code...
> >
> > What I'm seeing is for example: I open a report on my system, which has
> > previously accessed the report server and experience no delay. I go to
> > another system, which has never accessed that server, and run the same
> > report, and get a delay of up to a few minutes.
> >
> > Hope that is clear...
> >
> > Thanks for your help,
> >
> > Tom
> >
> > "Michael Cheng [MSFT]" wrote:
> >
> >> Hi Tomt,
> >>
> >> Thanks for your posting!
> >>
> >> From your descriptions, I understood that you would like to know why
> >> there
> >> will be a delay (a few minutes in some cases) when you first time access
> >> Reports. Have I understood you? Correct me if I was wrong.
> >>
> >> Based on my konwledge, this is Reporting Services by design behavior. The
> >> first user who runs the report with a unique region code creates a cached
> >> report that contains data for that region. Subsequent users who request a
> >> report using the same region code get the cached copy. create that report
> >> will cost a lot of time.
> >>
> >> The report server caches reports based on report execution options.
> >> Execution options determine whether a report is cached and the length of
> >> time it stays in cache. After some number of minutes or at a scheduled
> >> time, the cache is emptied. The cache stays empty until a new report
> >> execution operation occurs and a new copy of the report is cached.
> >>
> >> Thank you for your patience and corporation. If you have any questions or
> >> concerns, don't hesitate to let me know. We are always here to be of
> >> assistance!
> >>
> >>
> >> Sincerely yours,
> >>
> >> Michael Cheng
> >> Microsoft Online Partner Support
> >>
> >> When responding to posts, please "Reply to Group" via your newsreader so
> >> that others may learn and benefit from your issue.
> >> =====================================================> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
>
>|||Look for an earlier thread on this topic. Bruce and others have invented a
keep-alive type solution that periodically runs a trivial report on schedule
to keep the process from unloading.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"TomT" <tomt@.newsgroup.nospam> wrote in message
news:FACEA9F4-41FE-4C02-AD27-8FB118FB73AB@.microsoft.com...
> Ok, thanks. If that is the case, that is not the situation I'm talking
> about,
> it seems to be related to whether or not a system has ever accessed the
> server at all, there are no delays on systems that have, regardless of
> parameters.
> Thanks
> "Jeff A. Stucker" wrote:
>> I'm sure he meant report query parameters and region code was the
>> specific
>> one in his head for an example.
>> --
>> Cheers,
>> '(' Jeff A. Stucker
>> \
>> Business Intelligence
>> www.criadvantage.com
>> ---
>> "TomT" <tomt@.newsgroup.nospam> wrote in message
>> news:FC1995F8-D81D-4049-87EC-4B88A4DDB8BB@.microsoft.com...
>> > Michael,
>> >
>> > I'm not sure what you mean by region code...
>> >
>> > What I'm seeing is for example: I open a report on my system, which has
>> > previously accessed the report server and experience no delay. I go to
>> > another system, which has never accessed that server, and run the same
>> > report, and get a delay of up to a few minutes.
>> >
>> > Hope that is clear...
>> >
>> > Thanks for your help,
>> >
>> > Tom
>> >
>> > "Michael Cheng [MSFT]" wrote:
>> >
>> >> Hi Tomt,
>> >>
>> >> Thanks for your posting!
>> >>
>> >> From your descriptions, I understood that you would like to know why
>> >> there
>> >> will be a delay (a few minutes in some cases) when you first time
>> >> access
>> >> Reports. Have I understood you? Correct me if I was wrong.
>> >>
>> >> Based on my konwledge, this is Reporting Services by design behavior.
>> >> The
>> >> first user who runs the report with a unique region code creates a
>> >> cached
>> >> report that contains data for that region. Subsequent users who
>> >> request a
>> >> report using the same region code get the cached copy. create that
>> >> report
>> >> will cost a lot of time.
>> >>
>> >> The report server caches reports based on report execution options.
>> >> Execution options determine whether a report is cached and the length
>> >> of
>> >> time it stays in cache. After some number of minutes or at a scheduled
>> >> time, the cache is emptied. The cache stays empty until a new report
>> >> execution operation occurs and a new copy of the report is cached.
>> >>
>> >> Thank you for your patience and corporation. If you have any questions
>> >> or
>> >> concerns, don't hesitate to let me know. We are always here to be of
>> >> assistance!
>> >>
>> >>
>> >> Sincerely yours,
>> >>
>> >> Michael Cheng
>> >> Microsoft Online Partner Support
>> >>
>> >> When responding to posts, please "Reply to Group" via your newsreader
>> >> so
>> >> that others may learn and benefit from your issue.
>> >> =====================================================>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >>
>> >>
>>|||Thanks Jeff, that was my thread, I believe, which I started over because of
profile issues - and to get MS involved.
Unfortunately, that solution is not applicable to the problem I am
describing, apparently not very well...:-)
Here's a clearer scenario (I hope): I run report A on my system, it opens
immediately (my system has run reports previously, not necessarily report A,
however).
I goimmediately to another system , which has never run any reports at all,
and run report A. In many (although not all) cases, minutes will pass before
the report processing is competed. Since the time between running the report
on one system and the other is miniscule, I don't think the process is
unloading - there appears to be something else going on...
"Jeff A. Stucker" wrote:
> Look for an earlier thread on this topic. Bruce and others have invented a
> keep-alive type solution that periodically runs a trivial report on schedule
> to keep the process from unloading.
> --
> Cheers,
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---
> "TomT" <tomt@.newsgroup.nospam> wrote in message
> news:FACEA9F4-41FE-4C02-AD27-8FB118FB73AB@.microsoft.com...
> > Ok, thanks. If that is the case, that is not the situation I'm talking
> > about,
> > it seems to be related to whether or not a system has ever accessed the
> > server at all, there are no delays on systems that have, regardless of
> > parameters.
> >
> > Thanks
> >
> > "Jeff A. Stucker" wrote:
> >
> >> I'm sure he meant report query parameters and region code was the
> >> specific
> >> one in his head for an example.
> >>
> >> --
> >> Cheers,
> >>
> >> '(' Jeff A. Stucker
> >> \
> >>
> >> Business Intelligence
> >> www.criadvantage.com
> >> ---
> >> "TomT" <tomt@.newsgroup.nospam> wrote in message
> >> news:FC1995F8-D81D-4049-87EC-4B88A4DDB8BB@.microsoft.com...
> >> > Michael,
> >> >
> >> > I'm not sure what you mean by region code...
> >> >
> >> > What I'm seeing is for example: I open a report on my system, which has
> >> > previously accessed the report server and experience no delay. I go to
> >> > another system, which has never accessed that server, and run the same
> >> > report, and get a delay of up to a few minutes.
> >> >
> >> > Hope that is clear...
> >> >
> >> > Thanks for your help,
> >> >
> >> > Tom
> >> >
> >> > "Michael Cheng [MSFT]" wrote:
> >> >
> >> >> Hi Tomt,
> >> >>
> >> >> Thanks for your posting!
> >> >>
> >> >> From your descriptions, I understood that you would like to know why
> >> >> there
> >> >> will be a delay (a few minutes in some cases) when you first time
> >> >> access
> >> >> Reports. Have I understood you? Correct me if I was wrong.
> >> >>
> >> >> Based on my konwledge, this is Reporting Services by design behavior.
> >> >> The
> >> >> first user who runs the report with a unique region code creates a
> >> >> cached
> >> >> report that contains data for that region. Subsequent users who
> >> >> request a
> >> >> report using the same region code get the cached copy. create that
> >> >> report
> >> >> will cost a lot of time.
> >> >>
> >> >> The report server caches reports based on report execution options.
> >> >> Execution options determine whether a report is cached and the length
> >> >> of
> >> >> time it stays in cache. After some number of minutes or at a scheduled
> >> >> time, the cache is emptied. The cache stays empty until a new report
> >> >> execution operation occurs and a new copy of the report is cached.
> >> >>
> >> >> Thank you for your patience and corporation. If you have any questions
> >> >> or
> >> >> concerns, don't hesitate to let me know. We are always here to be of
> >> >> assistance!
> >> >>
> >> >>
> >> >> Sincerely yours,
> >> >>
> >> >> Michael Cheng
> >> >> Microsoft Online Partner Support
> >> >>
> >> >> When responding to posts, please "Reply to Group" via your newsreader
> >> >> so
> >> >> that others may learn and benefit from your issue.
> >> >> =====================================================> >> >> This posting is provided "AS IS" with no warranties, and confers no
> >> >> rights.
> >> >>
> >> >>
> >>
> >>
> >>
>
>|||Hi Tom,
What kind of credentials are used against the datasource?
Each IE and IIS do some hand shaking on the first request. It is also
possible that domain authentication or the first connection to the data
source lead to this kind of delay.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Michael,
Thanks for your response. It does appear to be related to the user. I logged
onto a system which had never accessed the report server, and got the report
right away. I then had another person log on to the same machine, and he got
a delay.
I am using a shared data source to access the actual sql server data, so
that is common to everyone, in other words the authentication for the reports
to the sql server data is not specific to individual users, their credentials
are not used.
I wonder if the IIS server (which is the same machine as the Report Server)
is a factor in the delay? People can get to the server without delays, it
just happens when they run their first report...
"Michael Cheng [MSFT]" wrote:
> Hi Tom,
> What kind of credentials are used against the datasource?
> Each IE and IIS do some hand shaking on the first request. It is also
> possible that domain authentication or the first connection to the data
> source lead to this kind of delay.
>
> Sincerely yours,
> Michael Cheng
> Microsoft Online Partner Support
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> =====================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

First Time Delay on Client Systems

I've just set up a SQL Reporting Services server.
All seems to be working fine, however I've noticed that when a report is
opened from a user system accessing the report server for the first time, the
report takes a very long time to open (a few minutes in some cases), and
sometimes I have to abort it and start again.
This is a report that should take a couple of seconds at most. Once the
report does finally open, it opens fine from then on, even when refreshed, or
run by different parameters. Also all other reports availale to the user also
run fine after that first one finally opens.
There are no errors, just the Report is being generated message. It's like
the server has to get aquainted with the machine accessing it the first
time...
Again, once the report has run, this problem goes away. I have tested this
on around 10 different user systems, with the same results on all of them,
some are Win2k, some are XP. The report server is running on a dual
processor, clean install Server 2003, SQL Server 2000 sp 3a.
Any assistance would be greatly appreciated. I'm holding off a full on roll
out of this until I get this solved, as it will certainly drive users crazy.
Thanks,
TomTIs this the first time *each* user runs the same report, or the first time
*any* user runs the same report?
If it's the first time each user runs the report (which your message seems
to say), it may be some overhead in setting up a user cache (just grasping
at straws here). It would be interesting to run a SQL performance monitor
and some other administrative performance tools when this happens. Perhaps
you could set logging to verbose for a moment.
If it's the first time any user runs the report, then it could be a source
database (back end) issue. Perhaps it's compiling the SQL statement for the
first time, and then the statement is in cache from then on. Or perhaps
it's setting up automatic indexes on the data the first time, and they're
there after that. Or, ...
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"TomT" <tomt@.tomt.com> wrote in message
news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> I've just set up a SQL Reporting Services server.
> All seems to be working fine, however I've noticed that when a report is
> opened from a user system accessing the report server for the first time,
> the
> report takes a very long time to open (a few minutes in some cases), and
> sometimes I have to abort it and start again.
> This is a report that should take a couple of seconds at most. Once the
> report does finally open, it opens fine from then on, even when refreshed,
> or
> run by different parameters. Also all other reports availale to the user
> also
> run fine after that first one finally opens.
> There are no errors, just the Report is being generated message. It's like
> the server has to get aquainted with the machine accessing it the first
> time...
> Again, once the report has run, this problem goes away. I have tested this
> on around 10 different user systems, with the same results on all of them,
> some are Win2k, some are XP. The report server is running on a dual
> processor, clean install Server 2003, SQL Server 2000 sp 3a.
> Any assistance would be greatly appreciated. I'm holding off a full on
> roll
> out of this until I get this solved, as it will certainly drive users
> crazy.
> Thanks,
> TomT|||Jeff,
Thanks for your reply. This is when each user runs any report from their
system for the first time. E.g., I could run it from my system and it runs
properly, however if a user who has never accessed the report server before
runs the same report, there is a significant delay. Once it finally opens,
things run properly for that user from then on (at least so far). However,
user B, who has never accessed the server, gets the delay.
A bit disappointing, really...
"Jeff A. Stucker" wrote:
> Is this the first time *each* user runs the same report, or the first time
> *any* user runs the same report?
> If it's the first time each user runs the report (which your message seems
> to say), it may be some overhead in setting up a user cache (just grasping
> at straws here). It would be interesting to run a SQL performance monitor
> and some other administrative performance tools when this happens. Perhaps
> you could set logging to verbose for a moment.
> If it's the first time any user runs the report, then it could be a source
> database (back end) issue. Perhaps it's compiling the SQL statement for the
> first time, and then the statement is in cache from then on. Or perhaps
> it's setting up automatic indexes on the data the first time, and they're
> there after that. Or, ...
> Cheers,
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---
> "TomT" <tomt@.tomt.com> wrote in message
> news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> > I've just set up a SQL Reporting Services server.
> >
> > All seems to be working fine, however I've noticed that when a report is
> > opened from a user system accessing the report server for the first time,
> > the
> > report takes a very long time to open (a few minutes in some cases), and
> > sometimes I have to abort it and start again.
> >
> > This is a report that should take a couple of seconds at most. Once the
> > report does finally open, it opens fine from then on, even when refreshed,
> > or
> > run by different parameters. Also all other reports availale to the user
> > also
> > run fine after that first one finally opens.
> >
> > There are no errors, just the Report is being generated message. It's like
> > the server has to get aquainted with the machine accessing it the first
> > time...
> >
> > Again, once the report has run, this problem goes away. I have tested this
> > on around 10 different user systems, with the same results on all of them,
> > some are Win2k, some are XP. The report server is running on a dual
> > processor, clean install Server 2003, SQL Server 2000 sp 3a.
> >
> > Any assistance would be greatly appreciated. I'm holding off a full on
> > roll
> > out of this until I get this solved, as it will certainly drive users
> > crazy.
> >
> > Thanks,
> >
> > TomT
>
>|||This is my experience. What I have seen is what matters is whether anyone
has hit the report server in awhile. It is not user or report specific. To
keep things predicatable I have a report open that is a very simple and
quick report that I set to autorefresh once a minute. This then prevents the
delay from happening.
You set autorefresh in the report properties. Try creating a report used
just by yourself to test this out.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"TomT" <tomt@.tomt.com> wrote in message
news:7FAEFC07-F89A-42BC-B095-28AD440314A5@.microsoft.com...
> Jeff,
> Thanks for your reply. This is when each user runs any report from their
> system for the first time. E.g., I could run it from my system and it runs
> properly, however if a user who has never accessed the report server
before
> runs the same report, there is a significant delay. Once it finally opens,
> things run properly for that user from then on (at least so far). However,
> user B, who has never accessed the server, gets the delay.
> A bit disappointing, really...
> "Jeff A. Stucker" wrote:
> > Is this the first time *each* user runs the same report, or the first
time
> > *any* user runs the same report?
> >
> > If it's the first time each user runs the report (which your message
seems
> > to say), it may be some overhead in setting up a user cache (just
grasping
> > at straws here). It would be interesting to run a SQL performance
monitor
> > and some other administrative performance tools when this happens.
Perhaps
> > you could set logging to verbose for a moment.
> >
> > If it's the first time any user runs the report, then it could be a
source
> > database (back end) issue. Perhaps it's compiling the SQL statement for
the
> > first time, and then the statement is in cache from then on. Or perhaps
> > it's setting up automatic indexes on the data the first time, and
they're
> > there after that. Or, ...
> >
> > Cheers,
> >
> > '(' Jeff A. Stucker
> > \
> >
> > Business Intelligence
> > www.criadvantage.com
> > ---
> > "TomT" <tomt@.tomt.com> wrote in message
> > news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> > > I've just set up a SQL Reporting Services server.
> > >
> > > All seems to be working fine, however I've noticed that when a report
is
> > > opened from a user system accessing the report server for the first
time,
> > > the
> > > report takes a very long time to open (a few minutes in some cases),
and
> > > sometimes I have to abort it and start again.
> > >
> > > This is a report that should take a couple of seconds at most. Once
the
> > > report does finally open, it opens fine from then on, even when
refreshed,
> > > or
> > > run by different parameters. Also all other reports availale to the
user
> > > also
> > > run fine after that first one finally opens.
> > >
> > > There are no errors, just the Report is being generated message. It's
like
> > > the server has to get aquainted with the machine accessing it the
first
> > > time...
> > >
> > > Again, once the report has run, this problem goes away. I have tested
this
> > > on around 10 different user systems, with the same results on all of
them,
> > > some are Win2k, some are XP. The report server is running on a dual
> > > processor, clean install Server 2003, SQL Server 2000 sp 3a.
> > >
> > > Any assistance would be greatly appreciated. I'm holding off a full on
> > > roll
> > > out of this until I get this solved, as it will certainly drive users
> > > crazy.
> > >
> > > Thanks,
> > >
> > > TomT
> >
> >
> >|||Ditto. I noticed it occurring more on the very first time RS was accessed
or after sufficient 'idle' time. I hadn't got around to working around the
issue just yet, but your work around seems good. In the back of my mind I
was thinking of writing a simple .rss script that does something like
ListChildren at the root folder and putting it on a schedule (once every n
minutes or so). My thinking was to just make a web service call and force
RS to re-cache whatever it had expired from its cached information.
Of course, I don't know if RS is expiring cached info or what...it would be
nice if MS would jump in an let us know exactly was happening here...
--
Adrian M.
MCP
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:uoFR3HdFFHA.3272@.TK2MSFTNGP10.phx.gbl...
> This is my experience. What I have seen is what matters is whether anyone
> has hit the report server in awhile. It is not user or report specific. To
> keep things predicatable I have a report open that is a very simple and
> quick report that I set to autorefresh once a minute. This then prevents
> the
> delay from happening.
> You set autorefresh in the report properties. Try creating a report used
> just by yourself to test this out.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "TomT" <tomt@.tomt.com> wrote in message
> news:7FAEFC07-F89A-42BC-B095-28AD440314A5@.microsoft.com...
>> Jeff,
>> Thanks for your reply. This is when each user runs any report from their
>> system for the first time. E.g., I could run it from my system and it
>> runs
>> properly, however if a user who has never accessed the report server
> before
>> runs the same report, there is a significant delay. Once it finally
>> opens,
>> things run properly for that user from then on (at least so far).
>> However,
>> user B, who has never accessed the server, gets the delay.
>> A bit disappointing, really...
>> "Jeff A. Stucker" wrote:
>> > Is this the first time *each* user runs the same report, or the first
> time
>> > *any* user runs the same report?
>> >
>> > If it's the first time each user runs the report (which your message
> seems
>> > to say), it may be some overhead in setting up a user cache (just
> grasping
>> > at straws here). It would be interesting to run a SQL performance
> monitor
>> > and some other administrative performance tools when this happens.
> Perhaps
>> > you could set logging to verbose for a moment.
>> >
>> > If it's the first time any user runs the report, then it could be a
> source
>> > database (back end) issue. Perhaps it's compiling the SQL statement
>> > for
> the
>> > first time, and then the statement is in cache from then on. Or
>> > perhaps
>> > it's setting up automatic indexes on the data the first time, and
> they're
>> > there after that. Or, ...
>> >
>> > Cheers,
>> >
>> > '(' Jeff A. Stucker
>> > \
>> >
>> > Business Intelligence
>> > www.criadvantage.com
>> > ---
>> > "TomT" <tomt@.tomt.com> wrote in message
>> > news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
>> > > I've just set up a SQL Reporting Services server.
>> > >
>> > > All seems to be working fine, however I've noticed that when a report
> is
>> > > opened from a user system accessing the report server for the first
> time,
>> > > the
>> > > report takes a very long time to open (a few minutes in some cases),
> and
>> > > sometimes I have to abort it and start again.
>> > >
>> > > This is a report that should take a couple of seconds at most. Once
> the
>> > > report does finally open, it opens fine from then on, even when
> refreshed,
>> > > or
>> > > run by different parameters. Also all other reports availale to the
> user
>> > > also
>> > > run fine after that first one finally opens.
>> > >
>> > > There are no errors, just the Report is being generated message. It's
> like
>> > > the server has to get aquainted with the machine accessing it the
> first
>> > > time...
>> > >
>> > > Again, once the report has run, this problem goes away. I have tested
> this
>> > > on around 10 different user systems, with the same results on all of
> them,
>> > > some are Win2k, some are XP. The report server is running on a dual
>> > > processor, clean install Server 2003, SQL Server 2000 sp 3a.
>> > >
>> > > Any assistance would be greatly appreciated. I'm holding off a full
>> > > on
>> > > roll
>> > > out of this until I get this solved, as it will certainly drive users
>> > > crazy.
>> > >
>> > > Thanks,
>> > >
>> > > TomT
>> >
>> >
>> >
>|||If you are running Windows 2003 server for your IIS reportserver, then this
is a simple issue - I'll explain what happens:
The report service engine, once it is idle for more than the default 20
minutes, the worker process is shutdown.
This is controlled by IIS.
Open up the Internet Information Services (IIS) Manager
Expand the server node then the application pools.
On my IIS machine, I created an application pool dedicated to the
reportserver & reportmanager virtual webs.
But anyways, for the application pool that the reportserver is pointing to
if you left everything to their defaults will be the DefaultAppPool.
Right click the default app pool and select properties.
There are two things that are checked by default - On the recycling tab
there is a checkbox for recycling worker processes - it is currently set to
1740 minutes (29 hours). Leave it.
The other one is on the performance tab - which is the one you are
interested in changing...
See the "Idle Timeout" section and increase the number of minutes to be 8
hours a typical working day - 8*60 = 480 minutes.
Next, to be sure the "morning person" that runs the first report doesn't get
the delay, set up a schedule for either a dummy or adhoc report to fire off
like at 6am so that the report component worker processes get loaded.
I hope this helps you.
There is no need to have a report fire off every minute to keep things
alive - it is just that the report service was "unloaded" and needed to load
back up.
=-Chris
"TomT" <tomt@.tomt.com> wrote in message
news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> I've just set up a SQL Reporting Services server.
> All seems to be working fine, however I've noticed that when a report is
> opened from a user system accessing the report server for the first time,
> the
> report takes a very long time to open (a few minutes in some cases), and
> sometimes I have to abort it and start again.
> This is a report that should take a couple of seconds at most. Once the
> report does finally open, it opens fine from then on, even when refreshed,
> or
> run by different parameters. Also all other reports availale to the user
> also
> run fine after that first one finally opens.
> There are no errors, just the Report is being generated message. It's like
> the server has to get aquainted with the machine accessing it the first
> time...
> Again, once the report has run, this problem goes away. I have tested this
> on around 10 different user systems, with the same results on all of them,
> some are Win2k, some are XP. The report server is running on a dual
> processor, clean install Server 2003, SQL Server 2000 sp 3a.
> Any assistance would be greatly appreciated. I'm holding off a full on
> roll
> out of this until I get this solved, as it will certainly drive users
> crazy.
> Thanks,
> TomT|||Very good. I figured something like that was happening. Of course I can also
just set the report to be refreshed every 15 minutes instead of every
minute.
Thanks for the info. Your solution is the correct way. Mine is a hack but
works.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Christopher Conner" <someone@.someplace.com> wrote in message
news:e9GOK2dFFHA.1084@.tk2msftngp13.phx.gbl...
> If you are running Windows 2003 server for your IIS reportserver, then
this
> is a simple issue - I'll explain what happens:
> The report service engine, once it is idle for more than the default 20
> minutes, the worker process is shutdown.
> This is controlled by IIS.
> Open up the Internet Information Services (IIS) Manager
> Expand the server node then the application pools.
> On my IIS machine, I created an application pool dedicated to the
> reportserver & reportmanager virtual webs.
> But anyways, for the application pool that the reportserver is pointing to
> if you left everything to their defaults will be the DefaultAppPool.
> Right click the default app pool and select properties.
> There are two things that are checked by default - On the recycling tab
> there is a checkbox for recycling worker processes - it is currently set
to
> 1740 minutes (29 hours). Leave it.
> The other one is on the performance tab - which is the one you are
> interested in changing...
> See the "Idle Timeout" section and increase the number of minutes to be 8
> hours a typical working day - 8*60 = 480 minutes.
> Next, to be sure the "morning person" that runs the first report doesn't
get
> the delay, set up a schedule for either a dummy or adhoc report to fire
off
> like at 6am so that the report component worker processes get loaded.
> I hope this helps you.
> There is no need to have a report fire off every minute to keep things
> alive - it is just that the report service was "unloaded" and needed to
load
> back up.
> =-Chris
>
>
>
> "TomT" <tomt@.tomt.com> wrote in message
> news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> > I've just set up a SQL Reporting Services server.
> >
> > All seems to be working fine, however I've noticed that when a report is
> > opened from a user system accessing the report server for the first
time,
> > the
> > report takes a very long time to open (a few minutes in some cases), and
> > sometimes I have to abort it and start again.
> >
> > This is a report that should take a couple of seconds at most. Once the
> > report does finally open, it opens fine from then on, even when
refreshed,
> > or
> > run by different parameters. Also all other reports availale to the user
> > also
> > run fine after that first one finally opens.
> >
> > There are no errors, just the Report is being generated message. It's
like
> > the server has to get aquainted with the machine accessing it the first
> > time...
> >
> > Again, once the report has run, this problem goes away. I have tested
this
> > on around 10 different user systems, with the same results on all of
them,
> > some are Win2k, some are XP. The report server is running on a dual
> > processor, clean install Server 2003, SQL Server 2000 sp 3a.
> >
> > Any assistance would be greatly appreciated. I'm holding off a full on
> > roll
> > out of this until I get this solved, as it will certainly drive users
> > crazy.
> >
> > Thanks,
> >
> > TomT
>|||thx Christopher...
--
Adrian M.
MCP
"Christopher Conner" <someone@.someplace.com> wrote in message
news:e9GOK2dFFHA.1084@.tk2msftngp13.phx.gbl...
> If you are running Windows 2003 server for your IIS reportserver, then
> this is a simple issue - I'll explain what happens:
> The report service engine, once it is idle for more than the default 20
> minutes, the worker process is shutdown.
> This is controlled by IIS.
> Open up the Internet Information Services (IIS) Manager
> Expand the server node then the application pools.
> On my IIS machine, I created an application pool dedicated to the
> reportserver & reportmanager virtual webs.
> But anyways, for the application pool that the reportserver is pointing to
> if you left everything to their defaults will be the DefaultAppPool.
> Right click the default app pool and select properties.
> There are two things that are checked by default - On the recycling tab
> there is a checkbox for recycling worker processes - it is currently set
> to 1740 minutes (29 hours). Leave it.
> The other one is on the performance tab - which is the one you are
> interested in changing...
> See the "Idle Timeout" section and increase the number of minutes to be 8
> hours a typical working day - 8*60 = 480 minutes.
> Next, to be sure the "morning person" that runs the first report doesn't
> get the delay, set up a schedule for either a dummy or adhoc report to
> fire off like at 6am so that the report component worker processes get
> loaded.
> I hope this helps you.
> There is no need to have a report fire off every minute to keep things
> alive - it is just that the report service was "unloaded" and needed to
> load back up.
> =-Chris
>
>
>
> "TomT" <tomt@.tomt.com> wrote in message
> news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
>> I've just set up a SQL Reporting Services server.
>> All seems to be working fine, however I've noticed that when a report is
>> opened from a user system accessing the report server for the first time,
>> the
>> report takes a very long time to open (a few minutes in some cases), and
>> sometimes I have to abort it and start again.
>> This is a report that should take a couple of seconds at most. Once the
>> report does finally open, it opens fine from then on, even when
>> refreshed, or
>> run by different parameters. Also all other reports availale to the user
>> also
>> run fine after that first one finally opens.
>> There are no errors, just the Report is being generated message. It's
>> like
>> the server has to get aquainted with the machine accessing it the first
>> time...
>> Again, once the report has run, this problem goes away. I have tested
>> this
>> on around 10 different user systems, with the same results on all of
>> them,
>> some are Win2k, some are XP. The report server is running on a dual
>> processor, clean install Server 2003, SQL Server 2000 sp 3a.
>> Any assistance would be greatly appreciated. I'm holding off a full on
>> roll
>> out of this until I get this solved, as it will certainly drive users
>> crazy.
>> Thanks,
>> TomT
>|||Christopher,
Thanks for your help on this. I wonder though, if this is what is going on
in my case. E.g., if I open the report from my system, it runs normally.
Then, if I were to go to a system that had never accessed the report server
before, (right after I had opened it on my system), there is a delay, with
the Report Processing message lasting for up to several minutes.
Since the report had just run on my system, unless I'm missing something, I
don't see how what you described causes the delay on the other system.
Any ideas?
Thanks again,
Tom
"Christopher Conner" wrote:
> If you are running Windows 2003 server for your IIS reportserver, then this
> is a simple issue - I'll explain what happens:
> The report service engine, once it is idle for more than the default 20
> minutes, the worker process is shutdown.
> This is controlled by IIS.
> Open up the Internet Information Services (IIS) Manager
> Expand the server node then the application pools.
> On my IIS machine, I created an application pool dedicated to the
> reportserver & reportmanager virtual webs.
> But anyways, for the application pool that the reportserver is pointing to
> if you left everything to their defaults will be the DefaultAppPool.
> Right click the default app pool and select properties.
> There are two things that are checked by default - On the recycling tab
> there is a checkbox for recycling worker processes - it is currently set to
> 1740 minutes (29 hours). Leave it.
> The other one is on the performance tab - which is the one you are
> interested in changing...
> See the "Idle Timeout" section and increase the number of minutes to be 8
> hours a typical working day - 8*60 = 480 minutes.
> Next, to be sure the "morning person" that runs the first report doesn't get
> the delay, set up a schedule for either a dummy or adhoc report to fire off
> like at 6am so that the report component worker processes get loaded.
> I hope this helps you.
> There is no need to have a report fire off every minute to keep things
> alive - it is just that the report service was "unloaded" and needed to load
> back up.
> =-Chris
>
>
>
> "TomT" <tomt@.tomt.com> wrote in message
> news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> > I've just set up a SQL Reporting Services server.
> >
> > All seems to be working fine, however I've noticed that when a report is
> > opened from a user system accessing the report server for the first time,
> > the
> > report takes a very long time to open (a few minutes in some cases), and
> > sometimes I have to abort it and start again.
> >
> > This is a report that should take a couple of seconds at most. Once the
> > report does finally open, it opens fine from then on, even when refreshed,
> > or
> > run by different parameters. Also all other reports availale to the user
> > also
> > run fine after that first one finally opens.
> >
> > There are no errors, just the Report is being generated message. It's like
> > the server has to get aquainted with the machine accessing it the first
> > time...
> >
> > Again, once the report has run, this problem goes away. I have tested this
> > on around 10 different user systems, with the same results on all of them,
> > some are Win2k, some are XP. The report server is running on a dual
> > processor, clean install Server 2003, SQL Server 2000 sp 3a.
> >
> > Any assistance would be greatly appreciated. I'm holding off a full on
> > roll
> > out of this until I get this solved, as it will certainly drive users
> > crazy.
> >
> > Thanks,
> >
> > TomT
>
>|||Bruce,
My case is not whether the server has been hit recently or not, it's whether
a particular client has hit it. I.e., if I open a report from my system, it's
fine. If I immediately go to a system which has never hit the server before,
it takes quite awhile for the same report, or any other for that matter, to
open...
Thanks for your help
"Bruce L-C [MVP]" wrote:
> This is my experience. What I have seen is what matters is whether anyone
> has hit the report server in awhile. It is not user or report specific. To
> keep things predicatable I have a report open that is a very simple and
> quick report that I set to autorefresh once a minute. This then prevents the
> delay from happening.
> You set autorefresh in the report properties. Try creating a report used
> just by yourself to test this out.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "TomT" <tomt@.tomt.com> wrote in message
> news:7FAEFC07-F89A-42BC-B095-28AD440314A5@.microsoft.com...
> > Jeff,
> >
> > Thanks for your reply. This is when each user runs any report from their
> > system for the first time. E.g., I could run it from my system and it runs
> > properly, however if a user who has never accessed the report server
> before
> > runs the same report, there is a significant delay. Once it finally opens,
> > things run properly for that user from then on (at least so far). However,
> > user B, who has never accessed the server, gets the delay.
> >
> > A bit disappointing, really...
> >
> > "Jeff A. Stucker" wrote:
> >
> > > Is this the first time *each* user runs the same report, or the first
> time
> > > *any* user runs the same report?
> > >
> > > If it's the first time each user runs the report (which your message
> seems
> > > to say), it may be some overhead in setting up a user cache (just
> grasping
> > > at straws here). It would be interesting to run a SQL performance
> monitor
> > > and some other administrative performance tools when this happens.
> Perhaps
> > > you could set logging to verbose for a moment.
> > >
> > > If it's the first time any user runs the report, then it could be a
> source
> > > database (back end) issue. Perhaps it's compiling the SQL statement for
> the
> > > first time, and then the statement is in cache from then on. Or perhaps
> > > it's setting up automatic indexes on the data the first time, and
> they're
> > > there after that. Or, ...
> > >
> > > Cheers,
> > >
> > > '(' Jeff A. Stucker
> > > \
> > >
> > > Business Intelligence
> > > www.criadvantage.com
> > > ---
> > > "TomT" <tomt@.tomt.com> wrote in message
> > > news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> > > > I've just set up a SQL Reporting Services server.
> > > >
> > > > All seems to be working fine, however I've noticed that when a report
> is
> > > > opened from a user system accessing the report server for the first
> time,
> > > > the
> > > > report takes a very long time to open (a few minutes in some cases),
> and
> > > > sometimes I have to abort it and start again.
> > > >
> > > > This is a report that should take a couple of seconds at most. Once
> the
> > > > report does finally open, it opens fine from then on, even when
> refreshed,
> > > > or
> > > > run by different parameters. Also all other reports availale to the
> user
> > > > also
> > > > run fine after that first one finally opens.
> > > >
> > > > There are no errors, just the Report is being generated message. It's
> like
> > > > the server has to get aquainted with the machine accessing it the
> first
> > > > time...
> > > >
> > > > Again, once the report has run, this problem goes away. I have tested
> this
> > > > on around 10 different user systems, with the same results on all of
> them,
> > > > some are Win2k, some are XP. The report server is running on a dual
> > > > processor, clean install Server 2003, SQL Server 2000 sp 3a.
> > > >
> > > > Any assistance would be greatly appreciated. I'm holding off a full on
> > > > roll
> > > > out of this until I get this solved, as it will certainly drive users
> > > > crazy.
> > > >
> > > > Thanks,
> > > >
> > > > TomT
> > >
> > >
> > >
>
>|||Anyone from Microsoft care to comment on this?
"TomT" wrote:
> Christopher,
> Thanks for your help on this. I wonder though, if this is what is going on
> in my case. E.g., if I open the report from my system, it runs normally.
> Then, if I were to go to a system that had never accessed the report server
> before, (right after I had opened it on my system), there is a delay, with
> the Report Processing message lasting for up to several minutes.
> Since the report had just run on my system, unless I'm missing something, I
> don't see how what you described causes the delay on the other system.
> Any ideas?
> Thanks again,
> Tom
> "Christopher Conner" wrote:
> > If you are running Windows 2003 server for your IIS reportserver, then this
> > is a simple issue - I'll explain what happens:
> >
> > The report service engine, once it is idle for more than the default 20
> > minutes, the worker process is shutdown.
> >
> > This is controlled by IIS.
> >
> > Open up the Internet Information Services (IIS) Manager
> > Expand the server node then the application pools.
> > On my IIS machine, I created an application pool dedicated to the
> > reportserver & reportmanager virtual webs.
> > But anyways, for the application pool that the reportserver is pointing to
> > if you left everything to their defaults will be the DefaultAppPool.
> > Right click the default app pool and select properties.
> > There are two things that are checked by default - On the recycling tab
> > there is a checkbox for recycling worker processes - it is currently set to
> > 1740 minutes (29 hours). Leave it.
> >
> > The other one is on the performance tab - which is the one you are
> > interested in changing...
> > See the "Idle Timeout" section and increase the number of minutes to be 8
> > hours a typical working day - 8*60 = 480 minutes.
> >
> > Next, to be sure the "morning person" that runs the first report doesn't get
> > the delay, set up a schedule for either a dummy or adhoc report to fire off
> > like at 6am so that the report component worker processes get loaded.
> >
> > I hope this helps you.
> >
> > There is no need to have a report fire off every minute to keep things
> > alive - it is just that the report service was "unloaded" and needed to load
> > back up.
> >
> > =-Chris
> >
> >
> >
> >
> >
> >
> >
> > "TomT" <tomt@.tomt.com> wrote in message
> > news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> > > I've just set up a SQL Reporting Services server.
> > >
> > > All seems to be working fine, however I've noticed that when a report is
> > > opened from a user system accessing the report server for the first time,
> > > the
> > > report takes a very long time to open (a few minutes in some cases), and
> > > sometimes I have to abort it and start again.
> > >
> > > This is a report that should take a couple of seconds at most. Once the
> > > report does finally open, it opens fine from then on, even when refreshed,
> > > or
> > > run by different parameters. Also all other reports availale to the user
> > > also
> > > run fine after that first one finally opens.
> > >
> > > There are no errors, just the Report is being generated message. It's like
> > > the server has to get aquainted with the machine accessing it the first
> > > time...
> > >
> > > Again, once the report has run, this problem goes away. I have tested this
> > > on around 10 different user systems, with the same results on all of them,
> > > some are Win2k, some are XP. The report server is running on a dual
> > > processor, clean install Server 2003, SQL Server 2000 sp 3a.
> > >
> > > Any assistance would be greatly appreciated. I'm holding off a full on
> > > roll
> > > out of this until I get this solved, as it will certainly drive users
> > > crazy.
> > >
> > > Thanks,
> > >
> > > TomT
> >
> >
> >|||Actually, this is a different issue - remember, the report manager uses NT
authentication - so it has to validate the user before allowing them access
to those resources - in this case - the report manager so you can view the
reports.
I have some customers who have domain controllers that take forever (i.e. a
few minutes "delay" on logon) when the user signs onto the domain.
On the web server that is running your report manager, find out what domain
controller is authenicating the users - you can do this by going to the
command prompt and typing "Set logonserver" and it will tell you the name of
the DC that is authenticating your users for the resources on the machine.
I use the "divide & conquer" method to troubleshooting. Lets try to
eliminate what the cause is. I would recommend, ONLY FOR A TEST, that you
access the report anonymously (allow anonymous) and bypass the
authentication. Of course, I do not know if this is possible. But at least
this would tell you whether the slow down is based on getting users
authenticated with the resources, or a different issue entirely.
I wish I could provide more information.
=-Chris
"TomT" <tomt@.tomt.com> wrote in message
news:EF3E6243-43D8-42A0-A027-84C58B638553@.microsoft.com...
> Christopher,
> Thanks for your help on this. I wonder though, if this is what is going on
> in my case. E.g., if I open the report from my system, it runs normally.
> Then, if I were to go to a system that had never accessed the report
> server
> before, (right after I had opened it on my system), there is a delay, with
> the Report Processing message lasting for up to several minutes.
> Since the report had just run on my system, unless I'm missing something,
> I
> don't see how what you described causes the delay on the other system.
> Any ideas?
> Thanks again,
> Tom
> "Christopher Conner" wrote:
>> If you are running Windows 2003 server for your IIS reportserver, then
>> this
>> is a simple issue - I'll explain what happens:
>> The report service engine, once it is idle for more than the default 20
>> minutes, the worker process is shutdown.
>> This is controlled by IIS.
>> Open up the Internet Information Services (IIS) Manager
>> Expand the server node then the application pools.
>> On my IIS machine, I created an application pool dedicated to the
>> reportserver & reportmanager virtual webs.
>> But anyways, for the application pool that the reportserver is pointing
>> to
>> if you left everything to their defaults will be the DefaultAppPool.
>> Right click the default app pool and select properties.
>> There are two things that are checked by default - On the recycling tab
>> there is a checkbox for recycling worker processes - it is currently set
>> to
>> 1740 minutes (29 hours). Leave it.
>> The other one is on the performance tab - which is the one you are
>> interested in changing...
>> See the "Idle Timeout" section and increase the number of minutes to be 8
>> hours a typical working day - 8*60 = 480 minutes.
>> Next, to be sure the "morning person" that runs the first report doesn't
>> get
>> the delay, set up a schedule for either a dummy or adhoc report to fire
>> off
>> like at 6am so that the report component worker processes get loaded.
>> I hope this helps you.
>> There is no need to have a report fire off every minute to keep things
>> alive - it is just that the report service was "unloaded" and needed to
>> load
>> back up.
>> =-Chris
>>
>>
>>
>> "TomT" <tomt@.tomt.com> wrote in message
>> news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
>> > I've just set up a SQL Reporting Services server.
>> >
>> > All seems to be working fine, however I've noticed that when a report
>> > is
>> > opened from a user system accessing the report server for the first
>> > time,
>> > the
>> > report takes a very long time to open (a few minutes in some cases),
>> > and
>> > sometimes I have to abort it and start again.
>> >
>> > This is a report that should take a couple of seconds at most. Once the
>> > report does finally open, it opens fine from then on, even when
>> > refreshed,
>> > or
>> > run by different parameters. Also all other reports availale to the
>> > user
>> > also
>> > run fine after that first one finally opens.
>> >
>> > There are no errors, just the Report is being generated message. It's
>> > like
>> > the server has to get aquainted with the machine accessing it the first
>> > time...
>> >
>> > Again, once the report has run, this problem goes away. I have tested
>> > this
>> > on around 10 different user systems, with the same results on all of
>> > them,
>> > some are Win2k, some are XP. The report server is running on a dual
>> > processor, clean install Server 2003, SQL Server 2000 sp 3a.
>> >
>> > Any assistance would be greatly appreciated. I'm holding off a full on
>> > roll
>> > out of this until I get this solved, as it will certainly drive users
>> > crazy.
>> >
>> > Thanks,
>> >
>> > TomT
>>|||Thanks Chris, I'll see if I can test that. According to our Domain guy tho,
we have a fast login validation. Also, so far it seems to be more machine
specific, as opposed to user accounts...
"Christopher Conner" wrote:
> Actually, this is a different issue - remember, the report manager uses NT
> authentication - so it has to validate the user before allowing them access
> to those resources - in this case - the report manager so you can view the
> reports.
> I have some customers who have domain controllers that take forever (i.e. a
> few minutes "delay" on logon) when the user signs onto the domain.
> On the web server that is running your report manager, find out what domain
> controller is authenicating the users - you can do this by going to the
> command prompt and typing "Set logonserver" and it will tell you the name of
> the DC that is authenticating your users for the resources on the machine.
> I use the "divide & conquer" method to troubleshooting. Lets try to
> eliminate what the cause is. I would recommend, ONLY FOR A TEST, that you
> access the report anonymously (allow anonymous) and bypass the
> authentication. Of course, I do not know if this is possible. But at least
> this would tell you whether the slow down is based on getting users
> authenticated with the resources, or a different issue entirely.
> I wish I could provide more information.
> =-Chris
>
> "TomT" <tomt@.tomt.com> wrote in message
> news:EF3E6243-43D8-42A0-A027-84C58B638553@.microsoft.com...
> > Christopher,
> >
> > Thanks for your help on this. I wonder though, if this is what is going on
> > in my case. E.g., if I open the report from my system, it runs normally.
> > Then, if I were to go to a system that had never accessed the report
> > server
> > before, (right after I had opened it on my system), there is a delay, with
> > the Report Processing message lasting for up to several minutes.
> >
> > Since the report had just run on my system, unless I'm missing something,
> > I
> > don't see how what you described causes the delay on the other system.
> >
> > Any ideas?
> >
> > Thanks again,
> >
> > Tom
> >
> > "Christopher Conner" wrote:
> >
> >> If you are running Windows 2003 server for your IIS reportserver, then
> >> this
> >> is a simple issue - I'll explain what happens:
> >>
> >> The report service engine, once it is idle for more than the default 20
> >> minutes, the worker process is shutdown.
> >>
> >> This is controlled by IIS.
> >>
> >> Open up the Internet Information Services (IIS) Manager
> >> Expand the server node then the application pools.
> >> On my IIS machine, I created an application pool dedicated to the
> >> reportserver & reportmanager virtual webs.
> >> But anyways, for the application pool that the reportserver is pointing
> >> to
> >> if you left everything to their defaults will be the DefaultAppPool.
> >> Right click the default app pool and select properties.
> >> There are two things that are checked by default - On the recycling tab
> >> there is a checkbox for recycling worker processes - it is currently set
> >> to
> >> 1740 minutes (29 hours). Leave it.
> >>
> >> The other one is on the performance tab - which is the one you are
> >> interested in changing...
> >> See the "Idle Timeout" section and increase the number of minutes to be 8
> >> hours a typical working day - 8*60 = 480 minutes.
> >>
> >> Next, to be sure the "morning person" that runs the first report doesn't
> >> get
> >> the delay, set up a schedule for either a dummy or adhoc report to fire
> >> off
> >> like at 6am so that the report component worker processes get loaded.
> >>
> >> I hope this helps you.
> >>
> >> There is no need to have a report fire off every minute to keep things
> >> alive - it is just that the report service was "unloaded" and needed to
> >> load
> >> back up.
> >>
> >> =-Chris
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> "TomT" <tomt@.tomt.com> wrote in message
> >> news:3031983D-75F9-466C-AD3A-3D76F0BEBDC5@.microsoft.com...
> >> > I've just set up a SQL Reporting Services server.
> >> >
> >> > All seems to be working fine, however I've noticed that when a report
> >> > is
> >> > opened from a user system accessing the report server for the first
> >> > time,
> >> > the
> >> > report takes a very long time to open (a few minutes in some cases),
> >> > and
> >> > sometimes I have to abort it and start again.
> >> >
> >> > This is a report that should take a couple of seconds at most. Once the
> >> > report does finally open, it opens fine from then on, even when
> >> > refreshed,
> >> > or
> >> > run by different parameters. Also all other reports availale to the
> >> > user
> >> > also
> >> > run fine after that first one finally opens.
> >> >
> >> > There are no errors, just the Report is being generated message. It's
> >> > like
> >> > the server has to get aquainted with the machine accessing it the first
> >> > time...
> >> >
> >> > Again, once the report has run, this problem goes away. I have tested
> >> > this
> >> > on around 10 different user systems, with the same results on all of
> >> > them,
> >> > some are Win2k, some are XP. The report server is running on a dual
> >> > processor, clean install Server 2003, SQL Server 2000 sp 3a.
> >> >
> >> > Any assistance would be greatly appreciated. I'm holding off a full on
> >> > roll
> >> > out of this until I get this solved, as it will certainly drive users
> >> > crazy.
> >> >
> >> > Thanks,
> >> >
> >> > TomT
> >>
> >>
> >>
>
>

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000. Since then the following has occurred.
1.Downloaded and Installed but not using the MS Office interop stuff (Client)
2.Downloaded and Installed MDAC 2.8(Client)
3.Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
(Server)
Thank you in advance for your help.
Other items that may help:
I have an Access 2003 ADP on the client that uses the same SQL Server DB and
it also takes 15 seconds before displaying the table objects. However, if I
close the adp and reopen it within 15 seconds, the tables display
immediately. If I close the adp and wait longer than 15 seconds, it takes 15
seconds to display the tables. Once the tables are displayed, access to data
within any table is sub second.
I tried this with my .Net application. Same result. If I restart my
application within 15 seconds, then access to SQL Server is sub-second. If I
restart my application after 15 seconds, then it takes 15 seconds to connect.
I have another adp on the Server that points to the same SQL Server
database. It opens and displays the tables immediately.
Enterprise Manager runs on the Server. As I drill down the tree to
databases>Tables>TblX>Return all rows responds as quickly as I can click the
nodes etc. However, if I right click on the database (or any of the standard
DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
first time.
Jim
Please refer to original. Sent duplicate in error. Sorry
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater if I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. However
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Server.
> I have not always had this problem. Unfortunately, I can’t say what I did
> that caused it, but the problem did not exist when I was running VS.Net 2003
> and the Server was running MSDE 2000. Since then the following has occurred.
> 1.Downloaded and Installed but not using the MS Office interop stuff (Client)
> 2.Downloaded and Installed MDAC 2.8(Client)
> 3.Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
> (Server)
> Thank you in advance for your help.
> Other items that may help:
> I have an Access 2003 ADP on the client that uses the same SQL Server DB and
> it also takes 15 seconds before displaying the table objects. However, if I
> close the adp and reopen it within 15 seconds, the tables display
> immediately. If I close the adp and wait longer than 15 seconds, it takes 15
> seconds to display the tables. Once the tables are displayed, access to data
> within any table is sub second.
> I tried this with my .Net application. Same result. If I restart my
> application within 15 seconds, then access to SQL Server is sub-second. If I
> restart my application after 15 seconds, then it takes 15 seconds to connect.
> I have another adp on the Server that points to the same SQL Server
> database. It opens and displays the tables immediately.
> Enterprise Manager runs on the Server. As I drill down the tree to
> databases>Tables>TblX>Return all rows responds as quickly as I can click the
> nodes etc. However, if I right click on the database (or any of the standard
> DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
> first time.
> --
> Jim

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000.
Jim
PLease Refer to my original. Sent Duplicate in error. Sorry.
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater if I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. However
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Server.
> I have not always had this problem. Unfortunately, I can’t say what I did
> that caused it, but the problem did not exist when I was running VS.Net 2003
> and the Server was running MSDE 2000.
> --
> Jim

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000. Since then the following has occurred.
1.Downloaded and Installed but not using the MS Office interop stuff (Client)
2.Downloaded and Installed MDAC 2.8(Client)
3.Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
(Server)
Thank you in advance for your help.
Other items that may help:
I have an Access 2003 ADP on the client that uses the same SQL Server DB and
it also takes 15 seconds before displaying the table objects. However, if I
close the adp and reopen it within 15 seconds, the tables display
immediately. If I close the adp and wait longer than 15 seconds, it takes 15
seconds to display the tables. Once the tables are displayed, access to data
within any table is sub second.
I tried this with my .Net application. Same result. If I restart my
application within 15 seconds, then access to SQL Server is sub-second. If I
restart my application after 15 seconds, then it takes 15 seconds to connect.
I have another adp on the Server that points to the same SQL Server
database. It opens and displays the tables immediately.
Enterprise Manager runs on the Server. As I drill down the tree to
databases>Tables>TblX>Return all rows responds as quickly as I can click the
nodes etc. However, if I right click on the database (or any of the standard
DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
first time.
Jim
PLEASE REFER TO MY ORIGINAL. I submitted 4. The first 3 came back with
Posting Error. Sorry.
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater if I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. However
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Server.
> I have not always had this problem. Unfortunately, I can’t say what I did
> that caused it, but the problem did not exist when I was running VS.Net 2003
> and the Server was running MSDE 2000. Since then the following has occurred.
> 1.Downloaded and Installed but not using the MS Office interop stuff (Client)
> 2.Downloaded and Installed MDAC 2.8(Client)
> 3.Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
> (Server)
> Thank you in advance for your help.
> Other items that may help:
> I have an Access 2003 ADP on the client that uses the same SQL Server DB and
> it also takes 15 seconds before displaying the table objects. However, if I
> close the adp and reopen it within 15 seconds, the tables display
> immediately. If I close the adp and wait longer than 15 seconds, it takes 15
> seconds to display the tables. Once the tables are displayed, access to data
> within any table is sub second.
> I tried this with my .Net application. Same result. If I restart my
> application within 15 seconds, then access to SQL Server is sub-second. If I
> restart my application after 15 seconds, then it takes 15 seconds to connect.
> I have another adp on the Server that points to the same SQL Server
> database. It opens and displays the tables immediately.
> Enterprise Manager runs on the Server. As I drill down the tree to
> databases>Tables>TblX>Return all rows responds as quickly as I can click the
> nodes etc. However, if I right click on the database (or any of the standard
> DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
> first time.
> --
> Jim

First Connection to SQL Server 2000 is slow (takes 15 seconds)

I have a client machine running VS.Net 2003, using TCP/IP to connect to a
server running SQL Server 2000 Developer. The first time I connect to the
server it always takes 15 seconds. Subsequent work on the server is very
quick but that first 15 seconds is extremely painful. It doesn’t mater if
I
perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The delay
is the same if I run an application from within the IDE or from a build. I
read about similar problems being solved with upgrades to MDAC 2.6. However
the Client runs 2.8 and the server runs 2.7 so that resolution does not
appear to apply. My Client is the only machine that connects with SQL Server
.
I have not always had this problem. Unfortunately, I can’t say what I did
that caused it, but the problem did not exist when I was running VS.Net 2003
and the Server was running MSDE 2000. Since then the following has occurred.
1. Downloaded and Installed but not using the MS Office interop stuff (Clien
t)
2. Downloaded and Installed MDAC 2.8 (Client)
3. Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
(Server)
Thank you in advance for your help.
Other items that may help:
I have an Access 2003 ADP on the client that uses the same SQL Server DB and
it also takes 15 seconds before displaying the table objects. However, if I
close the adp and reopen it within 15 seconds, the tables display
immediately. If I close the adp and wait longer than 15 seconds, it takes 15
seconds to display the tables. Once the tables are displayed, access to data
within any table is sub second.
I tried this with my .Net application. Same result. If I restart my
application within 15 seconds, then access to SQL Server is sub-second. If I
restart my application after 15 seconds, then it takes 15 seconds to connect
.
I have another adp on the Server that points to the same SQL Server
database. It opens and displays the tables immediately.
Enterprise Manager runs on the Server. As I drill down the tree to
databases>Tables>TblX>Return all rows responds as quickly as I can click the
nodes etc. However, if I right click on the database (or any of the standard
DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
first time.
JimPLEASE REFER TO MY ORIGINAL. I submitted 4. The first 3 came back with
Posting Error. Sorry.
"AdvanTouch" wrote:

> I have a client machine running VS.Net 2003, using TCP/IP to connect to a
> server running SQL Server 2000 Developer. The first time I connect to the
> server it always takes 15 seconds. Subsequent work on the server is very
> quick but that first 15 seconds is extremely painful. It doesn’t mater i
f I
> perform a DA.Fill(DS) or a cmd.open(), it still takes 15 seconds. The dela
y
> is the same if I run an application from within the IDE or from a build. I
> read about similar problems being solved with upgrades to MDAC 2.6. Howeve
r
> the Client runs 2.8 and the server runs 2.7 so that resolution does not
> appear to apply. My Client is the only machine that connects with SQL Serv
er.
> I have not always had this problem. Unfortunately, I can’t say what I di
d
> that caused it, but the problem did not exist when I was running VS.Net 20
03
> and the Server was running MSDE 2000. Since then the following has occurre
d.
> 1. Downloaded and Installed but not using the MS Office interop stuff (Cli
ent)
> 2. Downloaded and Installed MDAC 2.8 (Client)
> 3. Downloaded and Installed SQL Server 2000 Developer for Enterprise Mgr.
> (Server)
> Thank you in advance for your help.
> Other items that may help:
> I have an Access 2003 ADP on the client that uses the same SQL Server DB a
nd
> it also takes 15 seconds before displaying the table objects. However, if
I
> close the adp and reopen it within 15 seconds, the tables display
> immediately. If I close the adp and wait longer than 15 seconds, it takes
15
> seconds to display the tables. Once the tables are displayed, access to da
ta
> within any table is sub second.
> I tried this with my .Net application. Same result. If I restart my
> application within 15 seconds, then access to SQL Server is sub-second. If
I
> restart my application after 15 seconds, then it takes 15 seconds to conne
ct.
> I have another adp on the Server that points to the same SQL Server
> database. It opens and displays the tables immediately.
> Enterprise Manager runs on the Server. As I drill down the tree to
> databases>Tables>TblX>Return all rows responds as quickly as I can click t
he
> nodes etc. However, if I right click on the database (or any of the standa
rd
> DB’s (Master, Model, etc) and select properties, it takes 15 seconds the
> first time.
> --
> Jim