Hide Parameter with SP1

Installed SP1, still finding not possible to hide a parameter. Can someone provide the process please. The parameter is an ID that is send via URL to the report server. I created a Report Parameter for it, then created a queary parameter setting that to the incoming value of the Report Parameter. Help pleaseYou can hide a paremeter after you have deployed your report.
But hiding a parameter disallow you to pass any value to this parameter
through the URL!!!
The parameter is not simply hide to the user, is also completly inaccessible
to the user through any URL, but just available to the administrator to
change the default value of the parameter.
"Eddie" <Eddie@.discussions.microsoft.com> a écrit dans le message de
news:A077DD43-D64A-43DC-9D95-761106A4214E@.microsoft.com...
> Installed SP1, still finding not possible to hide a parameter. Can someone
provide the process please. The parameter is an ID that is send via URL to
the report server. I created a Report Parameter for it, then created a
queary parameter setting that to the incoming value of the Report Parameter.
Help please|||According to another post by Brian Welcker,
"This is onlt supported on the server. In Report Manager, leave the 'prompt
user' checkbox checked but clear our the prompt string. This should not
prompt the user but still allow you to specify them via URL."
with SP1, you should be able to specify in URL
"Jéjé" wrote:
> You can hide a paremeter after you have deployed your report.
> But hiding a parameter disallow you to pass any value to this parameter
> through the URL!!!
> The parameter is not simply hide to the user, is also completly inaccessible
> to the user through any URL, but just available to the administrator to
> change the default value of the parameter.
>
> "Eddie" <Eddie@.discussions.microsoft.com> a écrit dans le message de
> news:A077DD43-D64A-43DC-9D95-761106A4214E@.microsoft.com...
> > Installed SP1, still finding not possible to hide a parameter. Can someone
> provide the process please. The parameter is an ID that is send via URL to
> the report server. I created a Report Parameter for it, then created a
> queary parameter setting that to the incoming value of the Report Parameter.
> Help please
>
>|||From the SP1 Read Me:
4.3.1 Hiding Parameters in a Published Report
In Report Manager, you can now set parameter properties in a way that allows you to achieve two objectives simultaneously:
Hide the parameter fields in a published report.
Specify a parameter value at run time (for example, through a subscription that is used to trigger report execution and delivery).
Previously, the only way to hide a parameter value was to clear the Prompt User check box in the Parameters properties page. However, a side effect of clearing the check box was that you could no longer specify a parameter value for the report at run time. This limitation has been removed. In SP1, you can clear the Prompt User check box to hide the parameter fields and values in the report. Doing so does not introduce restrictions on how you subsequently set the parameter value externally at run time.
"Jéjé" wrote:
> You can hide a paremeter after you have deployed your report.
> But hiding a parameter disallow you to pass any value to this parameter
> through the URL!!!
> The parameter is not simply hide to the user, is also completly inaccessible
> to the user through any URL, but just available to the administrator to
> change the default value of the parameter.
>
> "Eddie" <Eddie@.discussions.microsoft.com> a écrit dans le message de
> news:A077DD43-D64A-43DC-9D95-761106A4214E@.microsoft.com...
> > Installed SP1, still finding not possible to hide a parameter. Can someone
> provide the process please. The parameter is an ID that is send via URL to
> the report server. I created a Report Parameter for it, then created a
> queary parameter setting that to the incoming value of the Report Parameter.
> Help please
>
>|||mmmm...
I'll test this.
maybe this doesn't works for me because I have a default value.
"Eddie" <Eddie@.discussions.microsoft.com> a écrit dans le message de
news:A3AD4330-FF88-46BD-97B8-58AB215F4507@.microsoft.com...
> From the SP1 Read Me:
> 4.3.1 Hiding Parameters in a Published Report
> In Report Manager, you can now set parameter properties in a way that
allows you to achieve two objectives simultaneously:
> Hide the parameter fields in a published report.
> Specify a parameter value at run time (for example, through a subscription
that is used to trigger report execution and delivery).
> Previously, the only way to hide a parameter value was to clear the Prompt
User check box in the Parameters properties page. However, a side effect of
clearing the check box was that you could no longer specify a parameter
value for the report at run time. This limitation has been removed. In SP1,
you can clear the Prompt User check box to hide the parameter fields and
values in the report. Doing so does not introduce restrictions on how you
subsequently set the parameter value externally at run time.
>
> "Jéjé" wrote:
> > You can hide a paremeter after you have deployed your report.
> > But hiding a parameter disallow you to pass any value to this parameter
> > through the URL!!!
> > The parameter is not simply hide to the user, is also completly
inaccessible
> > to the user through any URL, but just available to the administrator to
> > change the default value of the parameter.
> >
> >
> > "Eddie" <Eddie@.discussions.microsoft.com> a écrit dans le message de
> > news:A077DD43-D64A-43DC-9D95-761106A4214E@.microsoft.com...
> > > Installed SP1, still finding not possible to hide a parameter. Can
someone
> > provide the process please. The parameter is an ID that is send via URL
to
> > the report server. I created a Report Parameter for it, then created a
> > queary parameter setting that to the incoming value of the Report
Parameter.
> > Help please
> >
> >
> >|||Ok..
Now i have to create a subscription with specific parameters for this subscription and then i should uncheck Promt User checkbox?
Is that right?
The result report i'll use the parameter without problems?
"Eddie" wrote:
> From the SP1 Read Me:
> 4.3.1 Hiding Parameters in a Published Report
> In Report Manager, you can now set parameter properties in a way that allows you to achieve two objectives simultaneously:
> Hide the parameter fields in a published report.
> Specify a parameter value at run time (for example, through a subscription that is used to trigger report execution and delivery).
> Previously, the only way to hide a parameter value was to clear the Prompt User check box in the Parameters properties page. However, a side effect of clearing the check box was that you could no longer specify a parameter value for the report at run time. This limitation has been removed. In SP1, you can clear the Prompt User check box to hide the parameter fields and values in the report. Doing so does not introduce restrictions on how you subsequently set the parameter value externally at run time.

HELP? Multiple processes

I have a foreach loop which contains a call to an Execute process task. I want the Execute process task to run once for each element in my foreach, but I need to run as many Execute process tasks as my server can handle. What is the best way to do this? Any help would be greatly appreciated.

What do you mean by "I need to run as many Execute process tasks as my server can handle?" Can you be more precise in what this means, and perhaps provide a little more context on what exactly you're trying to accomplish?|||

Unfortunately, the ForEach container does not currently support parallel execution of the loops. And since the Execute Process task waits for a return value from the executable it calls, you are stuck in a sequential mode.

You can work around this by using multiple ForEach loops, and dividing your workload between them. However, this may take a bit more manual tuning. Or you migh be able to launch the process asynchronously from a script task.

|||

This is a vendor api that generates the data I need for my warehouse. I have a exe that takes one parameter and populates the appropriate stage0 tables. Sometimes this api runs really fast and returns little, other times it take 20 minutes. I'd like to run as many occurences of this api as possible so as not to slow my loads.

|||This may not be an appropriate task for SSIS then. Can you call the EXE from a C# app that has a thread pool and then when all instances of the EXE have finished running, yuo can launch whatever SSIS packes need to run next?|||

I've condsidered running it this way by passing an array of parms and then threading. I appreciate the response. I was just hoping there was a simplier and easier to maintain solution.

Help: KILL doesn't kill

I'm trying to kill a process (BACKUP DATABASE). It goes into KILLED/ROLLBAC
K
state. Kill WITH STATUSONLY says it's 100% rolled back with 0 time left to
finish. But the task stays around, and keeps both S and X locks on the
database.
This is apparently a repeatable problem. Is this an SQL Server 2000 bug?
What can I do? The server is a live application, I don't want to have to
cycle the server.
Thanks.I've heard of this happening and that it's an issue with SQL 2000 SP4,
related to a concurrency fix in Tempdb.
"Scott" wrote:

> I'm trying to kill a process (BACKUP DATABASE). It goes into KILLED/ROLLB
ACK
> state. Kill WITH STATUSONLY says it's 100% rolled back with 0 time left t
o
> finish. But the task stays around, and keeps both S and X locks on the
> database.
> This is apparently a repeatable problem. Is this an SQL Server 2000 bug?
> What can I do? The server is a live application, I don't want to have to
> cycle the server.
> Thanks.
>

Help: KILL doesn't kill

I'm trying to kill a process (BACKUP DATABASE). It goes into KILLED/ROLLBACK
state. Kill WITH STATUSONLY says it's 100% rolled back with 0 time left to
finish. But the task stays around, and keeps both S and X locks on the
database.
This is apparently a repeatable problem. Is this an SQL Server 2000 bug?
What can I do? The server is a live application, I don't want to have to
cycle the server.
Thanks.I've heard of this happening and that it's an issue with SQL 2000 SP4,
related to a concurrency fix in Tempdb.
"Scott" wrote:
> I'm trying to kill a process (BACKUP DATABASE). It goes into KILLED/ROLLBACK
> state. Kill WITH STATUSONLY says it's 100% rolled back with 0 time left to
> finish. But the task stays around, and keeps both S and X locks on the
> database.
> This is apparently a repeatable problem. Is this an SQL Server 2000 bug?
> What can I do? The server is a live application, I don't want to have to
> cycle the server.
> Thanks.
>

Help: KILL doesn't kill

I'm trying to kill a process (BACKUP DATABASE). It goes into KILLED/ROLLBACK
state. Kill WITH STATUSONLY says it's 100% rolled back with 0 time left to
finish. But the task stays around, and keeps both S and X locks on the
database.
This is apparently a repeatable problem. Is this an SQL Server 2000 bug?
What can I do? The server is a live application, I don't want to have to
cycle the server.
Thanks.
I've heard of this happening and that it's an issue with SQL 2000 SP4,
related to a concurrency fix in Tempdb.
"Scott" wrote:

> I'm trying to kill a process (BACKUP DATABASE). It goes into KILLED/ROLLBACK
> state. Kill WITH STATUSONLY says it's 100% rolled back with 0 time left to
> finish. But the task stays around, and keeps both S and X locks on the
> database.
> This is apparently a repeatable problem. Is this an SQL Server 2000 bug?
> What can I do? The server is a live application, I don't want to have to
> cycle the server.
> Thanks.
>

HELP: How to avoid ridiculous system resource issues when connecting to a huge Excel file

Hi all,

I have a 400MB Excel file that I consume from another automated process (don't ask). I copy this file down locally to my server, and I am attempting to create an SSIS package that points to this file via a connection manager. My computer starts gobbling up massive amounts of memory (devenv.exe gets up to about 800MB or so, then drops back down to 100MB) even when I attempt to rename the connection in the connection managers tab.

I have set all BypassPrepare to TRUE and ValidateExternalMetadata properties to FALSE, and still it can take up to 3 to 6 minutes for BI Dev Studio to respond. My specs:

Intel Centrino Duo 2.00 GHz

2GB RAM

XP Pro SP2

There MUST be a way for me to work effectively on a file of this size. Please help! Thanks much for any assistance.

Sincerely,

Brian Pulliam

Ok, so it sounds like it wants to read the entire file, a nice feature, and probably unavoidable.

Personally I would be developing and testing against a smaller file that is easier to work with, and easier to manipulate for test cases. Then when the bulk of the dev is ready run a test with the real file.

You may think this is a big issue, and whilst it would be nicer if it behaved better, what if this was a SQL load, woud you expect to dev against a 100GB database? Whilst the metadata would be OK, the simple running of a test would be impractical, so I'd still go with smaller test data during development.

|||

Just one more idea to try...

If you are using "Excel Source" try to use "OLEDB Source" instead and specify Microsoft Jet 4.0 OLE DB Provider.

If you are using Excel 2007, you should use the new ACE provider.

Regards,

Yitzhak

|||

In case if you don't have MS Office 2007 installed on your machine,

here is the link to donwload the connectivity components:

2007 Office System Driver: Data Connectivity Components.

http://www.microsoft.com/downloads/details.aspx?FamilyID=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=ja

Regards,

Yitzhak

|||

Thanks much for the reply Darren. I agree that a small subset of data would be great to test with. Actually I would dev against a 100GB database, although I would not pull all the data in my tests.

But your analogy to running a test on a 100GB DB is not very applicable. Firstly, I am not loading an entire DB. My Excel connection is pointing at one worksheet in an Excel 2003 file. And I have not even tried executing this package yet, I am nowhere near that far. Simply renaming the connection to the Excel file takes about 5 minutes before BI Developer Studio is responsive again. Also note that when connecting to a 100GB database, BI does not attempt to load the entire data set in that scenario. Maybe it has something to do with using an Excel file, that SSIS goes all paranoid and wants to look at the whole dang file.

Do you think if I set up a linked server to the Excel file in Management Studio that it might not have this problem? Maybe that would fake it into trusting the data source enough to not to the validation load. I attempted to do this on Friday but did not have much luck. Has anyone done this for an Excel 11.0 workbook?

Thanks again,

Brian